db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-919) improve pattern for setting up junit tests
Date Sun, 12 Mar 2006 21:20:54 GMT
     [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]

Kristian Waagan updated DERBY-919:
----------------------------------

    Attachment: BasicDerbyJUnitTest.java
                BasicDerbyJUnitTestTest.java
                BasicDerbyJUnitTest.html

In my opinion DerbyJUnitTest does not provide the most basic feature a JUnit test needs in
a proper way - to obtain a connection to some database. The critical point is the need to
call methods in a specific order for getConnection to work (not to get NullPointerExceptions).

Therefore I tried to write my own version of it, mostly to capture requirements. I have commented
the file pretty well, but I'm sure there are still areas where it does not explain enough.
Also, there will be lacking functionality regarding obtaining a connection, I would appreciate
people telling if they miss something (see also the questions further down). I also wrote
a simple test, which I hope demonstrate how BasicDerbyJUnitTest is intended to be used. Most
notably, it adapts to the settings set by our existing test harness.

DerbyJUnitTest has a lot more functionality than BasicDerbyJunitTest, and I propose to somehow
separate most/all the utility methods from the content of BasicDerbyJUnitTest to avoid cluttering
the class with a lot of unrelated functionality. This can be done either by inserting a new
class in the inheritance chain, or by creating a(nother) utility class. I do mean that the
utility methods existing today in DerbyJUnitTest is useful.

Questions regarding BasicDerbyJUnitTest:
a) Do we need to be able to get specific DataSource implementations, like EmbeddedSimple-,
*ConnectionPool*- and *XADataSource?
(functionality for specifying properties for DataSource connections is not yet implemented)
b) Should environment/version information (JVM, OS, maybe hardware) be available in/through
BasicDerbyJUniTest?

Questions regarding actions for JUnit infrastructure:
1) Is it okay to add yet another way to get connections?
2) I might be able to hack DerbyJUnitTest to work in a similar way as BasicDerbyJUnitTest,
but it is complicated by dependencies to existing tests. Also, it will not be a very clean
solution. Is this still something we want to do?
3) TestUtil is also used to get connections. It might also be possible to make this work as
BasicDerbyJunitTest, but then there is no reason to use (Basic)DerbyJUnitTest to get connections
for JUnit tests. Note that some methods, for instance TestUtil.getConnection(), is broken.

Feedback appreciated!

> improve pattern for setting up junit tests
> ------------------------------------------
>
>          Key: DERBY-919
>          URL: http://issues.apache.org/jira/browse/DERBY-919
>      Project: Derby
>         Type: Sub-task
>   Components: Test
>  Environment: All
>     Reporter: Andreas Korneliussen
>  Attachments: BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, BasicDerbyJUnitTestTest.java
>
> The current junit tests cannot be run directly from the java.ui.textrunner by i.e using:
> java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.junitTests.lang.BooleanTest
> .E
> Time: 0.008
> There was 1 error:
> 1) testBoolean(org.apache.derbyTesting.functionTests.tests.junitTests.lang.BooleanTest)java.lang.NullPointerException
>         at org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.faultInDriver(DerbyJUnitTest.java:317)
>         at org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.getConnection(DerbyJUnitTest.java:345)
>         at org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.getConnection(DerbyJUnitTest.java:335)
>         at org.apache.derbyTesting.functionTests.tests.junitTests.lang.BooleanTest.testBoolean(BooleanTest.java:136)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> FAILURES!!!
> Tests run: 1,  Failures: 0,  Errors: 1
> The reason is that the tests needs to have some fixture being set up before the test
can run, and that this is currently supported by calling a bunch of static methods in the
correct order to initialize some static members of DerbyJUnitTest.
> The proposed alternative is that the added fixture is set up in the suite() method, which
is used by JUnit to get the Test object to be run.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message