[ 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
