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] Commented: (DERBY-919) improve pattern for setting up junit tests
Date Mon, 13 Mar 2006 14:01:08 GMT
    [ http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370182 ] 

Kristian Waagan commented on DERBY-919:

I agree that the naming of the class can be changed.

I am not so sure if I fully agree with the proposed change regarding setUp().  I am more comfortable
with having test specific setups performed either in the test class' setUp method (called
before every test method) or in an associated TestSetup.setUp method (executed once before
a suite is run). Although I want the number of ways to get a connection to be as low as possible,
there must be ways to perform some specific things - like adding connection attributes when
testing database encryption or database restore. 
However, having a default setUp that creates a default connection is a good idea. The default
tearDown must then call either commit or rollback (most viable?), then close the connection.

Why do you want to create a data model and then tear it down for every test? I see this as
useful in some cases, but far from for all.
Also, why introduces abstract methods for something you already have a well defined location
for - setUp and tearDown?
If you need to add more complex logic to your setUp and tearDown methods, getting a default
connection is the least of your concerns - "con = getConnection();".

The reason why BasicDerbyJUnitTest does not use TestUtil to get connections are twofold; some
of the methods have limitations, and I thought it would be good to separate the mean of obtaining
a connection for new JUnit tests and old tests. 
For the former, there are no "getConnection()" method. Why specify arguments when you don't
need to? Also, "getConnection(String, String)" only returns embedded connections when using
For the latter, starting from scratch is good for seeing if we  can get rid of some unneded
things that have piled up as time has passed. I do know that it involves some code duplication,
but I find this acceptable in this case.

> 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)
> 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:
For more information on JIRA, see:

View raw message