db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren" <m.v.lunte...@gmail.com>
Subject Re: [jira] Updated: (DERBY-919) improve pattern for setting up junit tests
Date Sun, 12 Mar 2006 22:09:50 GMT
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
>
>

Mime
View raw message