Hi Kristian,
I will have a look at this patch, but also, please have a look at the patch I just made for DERBY-949. I changed TestUtil.getConnection() somewhat, hopefully this makes it work better...You don't specify in which way it is broken, so I'm guessing there.
Myrna
On 3/12/06, Kristian Waagan (JIRA) <derby-dev@db.apache.org> wrote:
[ 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
