You are viewing a plain text version of this content. The canonical link for it is here.

Posted to derby-dev@db.apache.org by "Andreas Korneliussen (JIRA)" <de...@db.apache.org> on 2006/02/03 13:25:03 UTC

[jira] Created: (DERBY-919) improve pattern for setting up junit tests

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
 Assigned to: Andreas Korneliussen 


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

Re: [jira] Updated: (DERBY-919) improve pattern for setting up junit tests

Posted by Kristian Waagan <Kr...@Sun.COM>.

David W. Van Couvering wrote:
> Hi, Kristian.  I am not sure I understand why you don't just use svn 
> diff to build your patch, rather than posting individual source files or 
> zipping/jarring/tarring/whatevering them up.  Is there a reason you 
> don't want to use svn diff?  It makes it *very* easy to apply, it's a 
> single file, and has useful information like the svn version you ran the 
> diff against.
> 
> If the diff file is too big, you can always zip up the diff file to 
> compress it.

Sorry David, it was just that these were all new files and some of them 
were already uploaded to Jira as individual files. So my mind 
short-circuited the svn add and svn diff process, which is of course the 
proper way of posting a patch for commit (along with a svn status as well).



--
Kristian

> 
> David
> 
> Kristian Waagan wrote:
>> Myrna van Lunteren wrote:
>>
>>> I had just downloaded v1.tar...I normally work on windows, so I have 
>>> to do some moving around to different machines to get tar files 
>>> unraveled. Is it bad to ask for a jar in future?
>>
>>
>> Sure, I'll use zip (jar) the next time :)
>>
>> Just to spread the word, tar is easily handled on Windows as well:
>> UltimateZip - http://www.ultimatezip.com/ (freeware)
>> WinZip - shareware
>> PowerArchiver - freeware
>> 7-zip - freeware
>> Tar for Windows - http://gnuwin32.sourceforge.net/packages/tar.htm
>>
>>>  
>>> I want to see if I can use this class to fix DERBY-993, so I'll 
>>> download v2 and see if I can modify the class to support JSR169 and 
>>> then modify the SUR* test to see if it works out.
>>
>>
>> Feel free to add the improvement to DERBY-1122, and also assign 
>> yourself  if you are currently working on it.
>>
>>
>>
>> -- 
>> Kristian
>>
>>>  
>>> But I can add that on as a patch afterwards, things look good to me 
>>> so far.
>>>  
>>> Myrna
>>>
>>>  
>>
>>
>> [snip]

Re: [jira] Updated: (DERBY-919) improve pattern for setting up junit tests

Posted by "David W. Van Couvering" <Da...@Sun.COM>.

Hi, Kristian.  I am not sure I understand why you don't just use svn 
diff to build your patch, rather than posting individual source files or 
zipping/jarring/tarring/whatevering them up.  Is there a reason you 
don't want to use svn diff?  It makes it *very* easy to apply, it's a 
single file, and has useful information like the svn version you ran the 
diff against.

If the diff file is too big, you can always zip up the diff file to 
compress it.

David

Kristian Waagan wrote:
> Myrna van Lunteren wrote:
> 
>> I had just downloaded v1.tar...I normally work on windows, so I have 
>> to do some moving around to different machines to get tar files 
>> unraveled. Is it bad to ask for a jar in future?
> 
> 
> Sure, I'll use zip (jar) the next time :)
> 
> Just to spread the word, tar is easily handled on Windows as well:
> UltimateZip - http://www.ultimatezip.com/ (freeware)
> WinZip - shareware
> PowerArchiver - freeware
> 7-zip - freeware
> Tar for Windows - http://gnuwin32.sourceforge.net/packages/tar.htm
> 
>>  
>> I want to see if I can use this class to fix DERBY-993, so I'll 
>> download v2 and see if I can modify the class to support JSR169 and 
>> then modify the SUR* test to see if it works out.
> 
> 
> Feel free to add the improvement to DERBY-1122, and also assign yourself 
>  if you are currently working on it.
> 
> 
> 
> -- 
> Kristian
> 
>>  
>> But I can add that on as a patch afterwards, things look good to me so 
>> far.
>>  
>> Myrna
>>
>>  
> 
> 
> [snip]

Re: [jira] Updated: (DERBY-919) improve pattern for setting up junit tests

Posted by Kristian Waagan <Kr...@Sun.COM>.

Myrna van Lunteren wrote:
> I had just downloaded v1.tar...I normally work on windows, so I have to 
> do some moving around to different machines to get tar files unraveled. 
> Is it bad to ask for a jar in future?

Sure, I'll use zip (jar) the next time :)

Just to spread the word, tar is easily handled on Windows as well:
UltimateZip - http://www.ultimatezip.com/ (freeware)
WinZip - shareware
PowerArchiver - freeware
7-zip - freeware
Tar for Windows - http://gnuwin32.sourceforge.net/packages/tar.htm

>  
> I want to see if I can use this class to fix DERBY-993, so I'll download 
> v2 and see if I can modify the class to support JSR169 and then modify 
> the SUR* test to see if it works out.

Feel free to add the improvement to DERBY-1122, and also assign yourself 
  if you are currently working on it.



--
Kristian

>  
> But I can add that on as a patch afterwards, things look good to me so far.
>  
> Myrna
> 
>  

[snip]

Re: [jira] Updated: (DERBY-919) improve pattern for setting up junit tests

Posted by Myrna van Lunteren <m....@gmail.com>.

I had just downloaded v1.tar...I normally work on windows, so I have to do
some moving around to different machines to get tar files unraveled. Is it
bad to ask for a jar in future?

I want to see if I can use this class to fix DERBY-993, so I'll download v2
and see if I can modify the class to support JSR169 and then modify the SUR*
test to see if it works out.

But I can add that on as a patch afterwards, things look good to me so far.

Myrna


On 3/16/06, Kristian Waagan (JIRA) <de...@db.apache.org> wrote:
>
>     [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]
>
> Kristian Waagan updated DERBY-919:
> ----------------------------------
>
>    Attachment: BaseJUnitTestClasses-v2.tar
>
> Thank you Andreas. See answers for your comments below.
>
> 1. I don't think this is necessary. An exception there merely implies we
> are in a JSR 169 environment, and that's all the static code is used for. If
> running under JSR 169, I would not like to see an exception being printed
> when running tests. I would then belive something was wrong, but it is not.
> And, if you are unable to load Driver in a non JSR 169 environment, then
> something is very wrong with the environment and the code will fail
> elsewhere.
>
> 2. Thanks for catching this. Forgot to remove while debugging privilege
> problems with the JCC driver.
>
> 3. I suggest you add this to the Jira issue I will create for tracking
> improvemens and bug for the JUnit base classes.
>
> Uploaded 'BaseJUnitTestClasses-v2-tar' which fixes 2. and  a missing
> @throws tag.
>
> > 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
> >     Assignee: Kristian Waagan
> >  Attachments: BaseJUnitTestClasses-v1.tar, BaseJUnitTestClasses-v2.tar,
> BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java,
> BasicDerbyJUnitTestTest.java, JDBCClient.java, TestConfiguration.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
>
>

Re: [jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by Andreas Korneliussen <An...@Sun.COM>.

> The discussions on this issue have confused me some. Is it the intention 
> to have a replacement for the ...functionTests/util/DerbyJUnitTest class?

Yes, the intention is to provide a common base class with can be reused 
when writing .junit tests. Initially the issue was to fix 
DerbyJUnitTest, and all the subclasses to be compatible with running 
tests as .junit. I think that is still a long term goal. However 
developers do want something they can use now, and they want to provide 
reusable Junit components. Therefore providing a new class may be the 
shortest path to that goal.

> Could it possibly be used in tests that currently run as .junit from 
> within the functionTests/harness ?
> Or would it be a third setup?
>  

This would be compatible with running tests as .junit.

Andreas

> Thx, Myrna
>

Re: [jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by Myrna van Lunteren <m....@gmail.com>.

On 3/15/06, Kristian Waagan (JIRA) <de...@db.apache.org> wrote:
>
>    [
> http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370620]
>
> Kristian Waagan commented on DERBY-919:
> ---------------------------------------
>
> Do we still need to have clients for both DB2 JCC and the "old net"
> framework?
> Based on contents of various classes, there seem to be some confusion (ie.
> that DB2JCC has JDBC prefix "jdbc:derby:net", others use "jdbc:db2:").
> Am I correct when saying we only need the "jdbc:derby:net" framework in
> the JDBCClient class, and that this client should be named either "DERBYNET"
> or "JCC"?
> (but not "DB2JCC", as this imply we are connecting to DB2, not Derby)

Right, We do still need support for 'jcc' or 'old net', because there are
customers and we - at IBM - need to test this setup. I think of this as
'DerbyNet' (jdbc:derby:net://...) and 'DerbyNetClient' (jdbc:derby://...)

But support for 'DB2JCC' or jdbc:db2: subprotocol is not needed at this
point, I think, that is from 'before contribution'.
That is, someone might at some time wish to run a test against DB2, so I
would not see it high priority to remove the references from existing files,
but I don't see why we would make an effort to put it in new files.

> Is the EmbeddedSimpleDataSource the only mean to create a connection in
> JSR 169?

Yes...The implementation that we use to test JSR 169 does not have any
java.sql.DriverManager classes.

The discussions on this issue have confused me some. Is it the intention to
have a replacement for the ...functionTests/util/DerbyJUnitTest class?
Could it possibly be used in tests that currently run as .junit from within
the functionTests/harness ?
Or would it be a third setup?

Thx, Myrna

Re: [jira] Updated: (DERBY-919) improve pattern for setting up junit tests

Posted by Myrna van Lunteren <m....@gmail.com>.

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) <de...@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
>
>

[jira] Updated: (DERBY-919) improve pattern for setting up junit tests

Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.

     [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]

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

    Attachment: BaseJUnitTestClasses-v2.tar

Thank you Andreas. See answers for your comments below.

1. I don't think this is necessary. An exception there merely implies we are in a JSR 169 environment, and that's all the static code is used for. If running under JSR 169, I would not like to see an exception being printed when running tests. I would then belive something was wrong, but it is not. And, if you are unable to load Driver in a non JSR 169 environment, then something is very wrong with the environment and the code will fail elsewhere.

2. Thanks for catching this. Forgot to remove while debugging privilege problems with the JCC driver.

3. I suggest you add this to the Jira issue I will create for tracking improvemens and bug for the JUnit base classes.

Uploaded 'BaseJUnitTestClasses-v2-tar' which fixes 2. and  a missing @throws tag.

> 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
>     Assignee: Kristian Waagan
>  Attachments: BaseJUnitTestClasses-v1.tar, BaseJUnitTestClasses-v2.tar, BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, BasicDerbyJUnitTestTest.java, JDBCClient.java, TestConfiguration.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

[jira] Updated: (DERBY-919) improve pattern for setting up junit tests

Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.

     [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]

Andreas Korneliussen updated DERBY-919:
---------------------------------------

    Fix Version: 10.2.0.0
        Version: 10.2.0.0

> 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
>     Versions: 10.2.0.0
>  Environment: All
>     Reporter: Andreas Korneliussen
>     Assignee: Kristian Waagan
>      Fix For: 10.2.0.0
>  Attachments: BaseJUnitTestClasses-v1.tar, BaseJUnitTestClasses-v2.tar, BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, BasicDerbyJUnitTestTest.java, JDBCClient.java, TestConfiguration.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

[jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.

    [ http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370620 ] 

Kristian Waagan commented on DERBY-919:
---------------------------------------

Do we still need to have clients for both DB2 JCC and the "old net" framework?
Based on contents of various classes, there seem to be some confusion (ie. that DB2JCC has JDBC prefix "jdbc:derby:net", others use "jdbc:db2:").
Am I correct when saying we only need the "jdbc:derby:net" framework in the JDBCClient class, and that this client should be named either "DERBYNET" or "JCC"? 
(but not "DB2JCC", as this imply we are connecting to DB2, not Derby)

Is the EmbeddedSimpleDataSource the only mean to create a connection in JSR 169?

> 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, JDBCClient.java, TestConfiguration.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

[jira] Updated: (DERBY-919) improve pattern for setting up junit tests

Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.

     [ 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

Re: [jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by Kristian Waagan <Kr...@Sun.COM>.

See answers inlined.

David W. Van Couvering wrote:

>
>
> Kristian Waagan wrote:
>
>>
>> So far most of the comments I have received have been regarding 
>> implementation, which was not my primary goal. Do we all agree what 
>> we need, but we want to do it in different ways? Or are there still 
>> someone out there that have more fundamental issues to comment on?
>
>
> I agree with Andreas: have a base generic class and a base class for JDBC
>
>>
>>
>>    /**
>>     * Get a connection to some database.
>>     * If the database does not exist, it will be created.
>>     * As long as the state of this class is not changed, this method 
>> will
>>     * return a connection to the same database. Most suites will 
>> require that
>>     * this condition is true.
>>     */
>>
>> My "as long as state of this class is not changed" was supposed to 
>> indicate that a connection to the same database was returned. "some" 
>> was chosen because a test should not generally care what the database 
>> it uses is named - as long as it is the same database for a given 
>> time (typically while running a single test method or a suite). This 
>> is a matter of wording.
>
>
> OK.  It's just not clear to me what "some database" is, and it took 
> some work for me to track it down.
>
>>> - You should document what the defaults are, such as "wombat" for 
>>> the database name and "APP" for username and password.
>>>   
>>
>>
>>
>> I did not do this, because most tests should not care.
>
>
> Why do you say that?  I'd like to know what's happening by default 
> before I use the default behavior of an API.

I see your point, but the knowledge you want to obtain is actually not 
*required* to write the tests. Whether you get a connection to database 
"wombat", "dog", "x" or something else will normally not affect your 
test code when testing the JDBC API. The same goes with username and 
password (as long as they are valid of course). A test should be 
self-contained and must itself take responsibility for ensuring its 
requirements are met - for instance populating the database or disabling 
autocommit.  Tests that need to know the name of the database should set 
this explicitly in the getConnection call, the same goes with username 
and password.

For instance when testing encryption of the database, different security 
mechanisms or backup/restore of a database, the no argument 
getConnection method would not be good enough. In my mind, if we 
suddenly decide to change the default database name from "wombat" to 
"holycow", no tests should fail. If a test fails because of this, it has 
put to much trust into the hands of getConnection() and should use 
getConnection(dbName) or a similar call where it specifies what it needs 
to know.

I still agree with you that the defaults should be documented though :)

>
>>
>>> - why can't setup() or teardown() automaticlly call resetState() 
>>> rather than asking the user to do it?  This seems dangerous and 
>>> highly error-prone.
>>>   
>>
>>
>>
>> When I wrote the class, I was looking at the JDBC4 test suite. It is 
>> configured to always run under DerbyNetClient, but it "internally" 
>> runs tests for embedded as well. BasicDerbyJUnitTest was written with 
>> the following paradigm in mind: do setup (basically set framework, 
>> maybe change default name and force use of datasource), then use 
>> getConnection() for all tests in suite. The setup would be done in a 
>> TestSetup decorator. With this approach, the test code can be exactly 
>> the same for multiple frameworks and/or setups, where as the test 
>> decorator would do different things for each suite. Calling 
>> resetState in TestCase.setUp() would delete the state setup by 
>> TestDecorator.setUp(). If this way to run tests are not needed, 
>> things can be rewritten (in many ways...).
>>
>
> OK, thanks for clarifying.  It would be good to provide this 
> discussion in the Javadoc so users know why they have to jump through 
> this particular hoop.  It also explains better the intent for this class.
>
> By the way, wouldn't separating configuration out from the base class 
> make this management of state go away?  You can pass in a non-default 
> configuration object and a non-default JDBCClient if you want to use 
> non-default behavior.
>
>>>
>>> - I don't understand why you set a property for the database name 
>>> before calling obtainConnection() rather than just passing in the 
>>> database name to obtainConnection().  It would be good to at least 
>>> explain the motivation behind this, as at first read it seems a bit 
>>> odd.  Scanning at the code, it looks like you use db(P_DBNAME) in 
>>> createBaseDatabaseUrl() where you could just as easily pass the 
>>> database name in as a parameter
>>>   
>>
>>
>>
>> All properties can be hardcoded and represented by constants instead 
>> of using a Properties object. I just wanted to signal that results 
>> are based on the state of the class, and that P_* are not set by 
>> environment properties, but that S_* are (passed on from the test 
>> harness). Andreas' TestConfiguration would separate this information 
>> from the class, which is good. I do think it is a bit too rigid as it 
>> is to give the required flexibility (not possible to change 
>> anything), but this is of course easily changed. It also give me the 
>> impression that every configurable aspect is passed on from the test 
>> harness, which is not yet true.
>
>
> Again, I think this whole thing goes away if you use the 
> TestConfiguratio model.  Right?
>
>>
>>> - You have a lot of useful debug statements, but your javadoc 
>>> doesn't really explain how to turn debug on and off, nor is it clear 
>>> from the class (e.g. there is not "debug(boolean)" method).
>>>   
>>
>>
>>
>> Would mentioning this in the public class documentation do the trick?
>
>
> Yes, that would help.
>
>>
>>> - It would be nice to have a helper method that allows subclasses to 
>>> quickly obtain other properties set by the harness (e.g. so they 
>>> don't have to do a privileged block every time they want to get a 
>>> system property)
>>>   
>>
>>
>>
>> Are you thinking of a getSystemProperty(key) with a privileged block, 
>> or a method accessing a "cached" system properties object?
>
>
> The former if system properties are not read-only, otherwise the 
> latter is fine with me.  Since accessing system properties directly 
> requires jumping through security hoops, I thought it would be good to 
> isolate it.
>
> Also, it would be very good to abstract out configuration 
> implementation details so that if we change the way tests are 
> configured all the tests don't have to change.  Another motivation for 
> the TestConfiguration class...

This could have been changed directly in BasicDerbyJUnitTest as well, 
but I agree the TestConfiguration class is a far better solution.

>
>>
>>> - I like Andreas' typesafe JDBCClient class, it seems a better 
>>> approach.
>>>   
>>
>>
>>
>> Yes. It should be extended to have information about DataSource 
>> classes also, or else it would not be sufficent in a JSR 169 (like) 
>> environment. Some complications here if we want to allow for more 
>> than one type of DataSource for a given framework (XA, Pooled, 
>> Simple, "normal").
>
>
> OK
>
Thanks for all the comments.
I have decided to discard BasicDerbyJUnit test entirely, it has served 
its purpose.
I hope to produce a very simple BaseJDBCTestCase and a minimal 
BaseTestCase shortly. I would appreciate if they could be commented 
quickly and commited as soon as they are acceptable.



--
Kristian

Re: [jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by "David W. Van Couvering" <Da...@Sun.COM>.


Kristian Waagan wrote:
> 
> So far most of the comments I have received have been regarding 
> implementation, which was not my primary goal. Do we all agree what we 
> need, but we want to do it in different ways? Or are there still someone 
> out there that have more fundamental issues to comment on?

I agree with Andreas: have a base generic class and a base class for JDBC

> 
> 
>    /**
>     * Get a connection to some database.
>     * If the database does not exist, it will be created.
>     * As long as the state of this class is not changed, this method will
>     * return a connection to the same database. Most suites will require 
> that
>     * this condition is true.
>     */
> 
> My "as long as state of this class is not changed" was supposed to 
> indicate that a connection to the same database was returned. "some" was 
> chosen because a test should not generally care what the database it 
> uses is named - as long as it is the same database for a given time 
> (typically while running a single test method or a suite). This is a 
> matter of wording.

OK.  It's just not clear to me what "some database" is, and it took some 
work for me to track it down.

>> - You should document what the defaults are, such as "wombat" for the 
>> database name and "APP" for username and password.
>>   
> 
> 
> I did not do this, because most tests should not care.

Why do you say that?  I'd like to know what's happening by default 
before I use the default behavior of an API.

> 
>> - why can't setup() or teardown() automaticlly call resetState() 
>> rather than asking the user to do it?  This seems dangerous and highly 
>> error-prone.
>>   
> 
> 
> When I wrote the class, I was looking at the JDBC4 test suite. It is 
> configured to always run under DerbyNetClient, but it "internally" runs 
> tests for embedded as well. BasicDerbyJUnitTest was written with the 
> following paradigm in mind: do setup (basically set framework, maybe 
> change default name and force use of datasource), then use 
> getConnection() for all tests in suite. The setup would be done in a 
> TestSetup decorator. With this approach, the test code can be exactly 
> the same for multiple frameworks and/or setups, where as the test 
> decorator would do different things for each suite. Calling resetState 
> in TestCase.setUp() would delete the state setup by 
> TestDecorator.setUp(). If this way to run tests are not needed, things 
> can be rewritten (in many ways...).
>

OK, thanks for clarifying.  It would be good to provide this discussion 
in the Javadoc so users know why they have to jump through this 
particular hoop.  It also explains better the intent for this class.

By the way, wouldn't separating configuration out from the base class 
make this management of state go away?  You can pass in a non-default 
configuration object and a non-default JDBCClient if you want to use 
non-default behavior.

>>
>> - I don't understand why you set a property for the database name 
>> before calling obtainConnection() rather than just passing in the 
>> database name to obtainConnection().  It would be good to at least 
>> explain the motivation behind this, as at first read it seems a bit 
>> odd.  Scanning at the code, it looks like you use db(P_DBNAME) in 
>> createBaseDatabaseUrl() where you could just as easily pass the 
>> database name in as a parameter
>>   
> 
> 
> All properties can be hardcoded and represented by constants instead of 
> using a Properties object. I just wanted to signal that results are 
> based on the state of the class, and that P_* are not set by environment 
> properties, but that S_* are (passed on from the test harness). Andreas' 
> TestConfiguration would separate this information from the class, which 
> is good. I do think it is a bit too rigid as it is to give the required 
> flexibility (not possible to change anything), but this is of course 
> easily changed. It also give me the impression that every configurable 
> aspect is passed on from the test harness, which is not yet true.

Again, I think this whole thing goes away if you use the 
TestConfiguratio model.  Right?

> 
>> - You have a lot of useful debug statements, but your javadoc doesn't 
>> really explain how to turn debug on and off, nor is it clear from the 
>> class (e.g. there is not "debug(boolean)" method).
>>   
> 
> 
> Would mentioning this in the public class documentation do the trick?

Yes, that would help.
> 
>> - It would be nice to have a helper method that allows subclasses to 
>> quickly obtain other properties set by the harness (e.g. so they don't 
>> have to do a privileged block every time they want to get a system 
>> property)
>>   
> 
> 
> Are you thinking of a getSystemProperty(key) with a privileged block, or 
> a method accessing a "cached" system properties object?

The former if system properties are not read-only, otherwise the latter 
is fine with me.  Since accessing system properties directly requires 
jumping through security hoops, I thought it would be good to isolate it.

Also, it would be very good to abstract out configuration implementation 
details so that if we change the way tests are configured all the tests 
don't have to change.  Another motivation for the TestConfiguration class...

> 
>> - I like Andreas' typesafe JDBCClient class, it seems a better approach.
>>   
> 
> 
> Yes. It should be extended to have information about DataSource classes 
> also, or else it would not be sufficent in a JSR 169 (like) environment. 
> Some complications here if we want to allow for more than one type of 
> DataSource for a given framework (XA, Pooled, Simple, "normal").

OK

Re: [jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by Myrna van Lunteren <m....@gmail.com>.

On 3/15/06, Andreas Korneliussen <An...@sun.com> wrote:
>
> Kristian Waagan wrote:
>
> > Also, it seems the harness uses all of "hostName", "
> derbyTesting.serverhost" and "derbyTesting.clienthost". Can anyone shed
> some light on this?
> I assume that derbyTesting.serverhost is the hostname for the derby
> server, derbyTesting.clienthost is the hostname for the client.
>
>
> Andreas

hostName is defaulted to 'localhost', but can be set with RunTest/RunSuite
to enable testing with the networkserver on another machine. This is
required for, for instance, IPV6 machine testing.
derbyTesting.serverhost and derbyTesting.clienthost are only relevant
because they are used in the derby_tests.policy file - they're *not* used
anywhere else.
(So the test harness sets derbyTesting.serverhost if hostName has been set
explicitly, otherwise it's always 'localhost').

I'll try to catch up on what is being mentioned in this discussion and join
the discussion...

Myrna

Re: [jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by Andreas Korneliussen <An...@Sun.COM>.

Kristian Waagan wrote:
> Answering these by mail, not Jira comment, as it is not the best way to 
> answer a lot of specific questions. Maybe I'll condense the discussion 
> and add a Jira comment later.
> Just to be clear, I do not primarily work on this issue. I just wanted 
> to bring out comments to get things started, and it does seem people 
> have some.
> 
> David Van Couvering (JIRA) wrote:
> 
>>     [ 
>> http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370400 
>> ]
>> David Van Couvering commented on DERBY-919:
>> -------------------------------------------
>>
>> I think it is great to have base unit test like this, although I agree 
>> with Andreas that this should be renamed.  This class is almost solely 
>> about obtaining connections using different frameworks, and is very 
>> JDBC-specific.  There are plenty of unit tests that have no need for 
>> this functionality.
>>   
> 
> 
> Yes, indeed. But then we are *almost* back to simply extending TestCase. 
> What tests not related to frameworks (and thus JDBC) need some kind of 
> common functionality? Including JDBC in the name seems like a solution. 
> Do we agree that non-JDBC tests should extend TestCase directly?
> 

I think it would be good to have a BaseTestCase which has access to the 
following:
* a TestConfiguration object
* and possibly some debug methods to log stack trace, print stuff.

BaseJDBCTestCase could extend this with some getConnection() methods.

>> I am not sure how this work integrates with/coincides with the work 
>> Andreas did to create a junit test type which allows you to run 'raw' 
>> JUnit tests under the harness.  Can you explain?
>>   
>
I think this work integrates well with the work to run tests a .junit.
You can confirm that by trying to run the sample testcase as .junit.

> 
> Andreas' work for running a "raw" JUnit test under the harness is not 
> affected. This is all about getting a connection and some other basic 
> functionality. It was written because the existing DerbyJUnitTest need 
> additional methods calls before getConnection() returns a valid 
> connection, and because TestUtil does not have a getConnection() (but 
> several other getConnection(arguments) methods). We have several choices:
> * Use TestUtil, maybe do some additional work on it.
> * Adapt/change DerbyJUnitTest (dependencies restrict what we can change 
> of existing API/behavior)
> * Write a new common class from scratch
>
> So far most of the comments I have received have been regarding 
> implementation, which was not my primary goal. Do we all agree what we 
> need, but we want to do it in different ways? Or are there still someone 
> out there that have more fundamental issues to comment on?
> 

I want:

BaseTestCase: a useful base TestCase which provides a TestConfiguration 
object, and some logging method
BaseJDBCTestCase: extends BaseTestCase, and additionally provides 
getConnection() methods.

How the getConnection() methods are implemented, is not the important 
issue to me. They may be implemented by calling TestUtil or implemented 
in the BaseJDBCTestCase itself. I do however think it is important to 
avoid forcing testcases to call methods to clean up potential 
side-effects from previous testcases.

Also, to run a TestCase as a test of type .junit, the testcase suite 
must be able to run stand-alone in a standard JUnit TestRunner .

<..>
>> - There are a lot of defaults being setup in a hardcoded fashion in 
>> resetState().  It would be better to have a section of static finals 
>> at the top with all the default values so that someone looking at this 
>> code can tell right away what they are.  Actually, looking at Andreas' 
>> TestConfiguration, that is a nice way of doing it . Having it as a 
>> separate class also seems to be useful and more coherent.
>>   
> 
> 
> One note here, is that it would not be possible to change the framework 
> with the current TestConfiguration. This would cause trouble for 
> exceptional cases (as the current JDBC4 testsuite) and if we want to run 
> useprocess=false and switch framework. Is this switching of framework 
> something we don't need?
> 
I do not see that we need switching framework in general. And .junit 
tests cannot be run with useprocess=false.

I think if you additionally supplied a getConnection(..) method which 
takes JDBCClient parameter, you could easily write special purpose 
testcases which do not use the default framework for getting the 
connectiom, if that is what you need.

> Also, it seems the harness uses all of "hostName", "derbyTesting.serverhost" and "derbyTesting.clienthost". Can anyone shed some light on this?
I assume that derbyTesting.serverhost is the hostname for the derby 
server, derbyTesting.clienthost is the hostname for the client.


Andreas

Re: [jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by Kristian Waagan <Kr...@Sun.COM>.

Answering these by mail, not Jira comment, as it is not the best way to 
answer a lot of specific questions. Maybe I'll condense the discussion 
and add a Jira comment later.
Just to be clear, I do not primarily work on this issue. I just wanted 
to bring out comments to get things started, and it does seem people 
have some.

David Van Couvering (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370400 ] 
>
> David Van Couvering commented on DERBY-919:
> -------------------------------------------
>
> I think it is great to have base unit test like this, although I agree with Andreas that this should be renamed.  This class is almost solely about obtaining connections using different frameworks, and is very JDBC-specific.  There are plenty of unit tests that have no need for this functionality.
>   

Yes, indeed. But then we are *almost* back to simply extending TestCase. 
What tests not related to frameworks (and thus JDBC) need some kind of 
common functionality? Including JDBC in the name seems like a solution. 
Do we agree that non-JDBC tests should extend TestCase directly?

> I am not sure how this work integrates with/coincides with the work Andreas did to create a junit test type which allows you to run 'raw' JUnit tests under the harness.  Can you explain?
>   

Andreas' work for running a "raw" JUnit test under the harness is not 
affected. This is all about getting a connection and some other basic 
functionality. It was written because the existing DerbyJUnitTest need 
additional methods calls before getConnection() returns a valid 
connection, and because TestUtil does not have a getConnection() (but 
several other getConnection(arguments) methods). We have several choices:
* Use TestUtil, maybe do some additional work on it.
* Adapt/change DerbyJUnitTest (dependencies restrict what we can change 
of existing API/behavior)
* Write a new common class from scratch

So far most of the comments I have received have been regarding 
implementation, which was not my primary goal. Do we all agree what we 
need, but we want to do it in different ways? Or are there still someone 
out there that have more fundamental issues to comment on?

> Here are my general comments...
>
> Javadoc:
> - getConnection() - it would be great to say it connects to the default database, instead of "some database", which is a little disconcerting as it sounds somewhat non-deterministic.
>   

    /**
     * Get a connection to some database.
     * If the database does not exist, it will be created.
     * As long as the state of this class is not changed, this method will
     * return a connection to the same database. Most suites will 
require that
     * this condition is true.
     */

My "as long as state of this class is not changed" was supposed to 
indicate that a connection to the same database was returned. "some" was 
chosen because a test should not generally care what the database it 
uses is named - as long as it is the same database for a given time 
(typically while running a single test method or a suite). This is a 
matter of wording.

> - You should document what the defaults are, such as "wombat" for the database name and "APP" for username and password.
>   

I did not do this, because most tests should not care.

> - why can't setup() or teardown() automaticlly call resetState() rather than asking the user to do it?  This seems dangerous and highly error-prone.
>   

When I wrote the class, I was looking at the JDBC4 test suite. It is 
configured to always run under DerbyNetClient, but it "internally" runs 
tests for embedded as well. BasicDerbyJUnitTest was written with the 
following paradigm in mind: do setup (basically set framework, maybe 
change default name and force use of datasource), then use 
getConnection() for all tests in suite. The setup would be done in a 
TestSetup decorator. With this approach, the test code can be exactly 
the same for multiple frameworks and/or setups, where as the test 
decorator would do different things for each suite. Calling resetState 
in TestCase.setUp() would delete the state setup by 
TestDecorator.setUp(). If this way to run tests are not needed, things 
can be rewritten (in many ways...).

> - when I try to click on a method name, I get a "404" error, although I can scroll directly down to view the method details.  I suspect this is probably just a JIRA bug.
>   

This is because I just copied a single Javadoc file and attached it. 
Jira is not to blame here. I did not find it necessary to upload all 
results generated when running javadoc.

> BaseDerbyJUnitTest:
>
> - I don't understand why you set a property for the database name before calling obtainConnection() rather than just passing in the database name to obtainConnection().  It would be good to at least explain the motivation behind this, as at first read it seems a bit odd.  Scanning at the code, it looks like you use db(P_DBNAME) in createBaseDatabaseUrl() where you could just as easily pass the database name in as a parameter
>   

All properties can be hardcoded and represented by constants instead of 
using a Properties object. I just wanted to signal that results are 
based on the state of the class, and that P_* are not set by environment 
properties, but that S_* are (passed on from the test harness). Andreas' 
TestConfiguration would separate this information from the class, which 
is good. I do think it is a bit too rigid as it is to give the required 
flexibility (not possible to change anything), but this is of course 
easily changed. It also give me the impression that every configurable 
aspect is passed on from the test harness, which is not yet true.

Also, it seems the harness uses all of "hostName", 
"derbyTesting.serverhost" and "derbyTesting.clienthost". Can anyone shed 
some light on this?

> - There are a lot of defaults being setup in a hardcoded fashion in resetState().  It would be better to have a section of static finals at the top with all the default values so that someone looking at this code can tell right away what they are.  Actually, looking at Andreas' TestConfiguration, that is a nice way of doing it . Having it as a separate class also seems to be useful and more coherent.
>   

One note here, is that it would not be possible to change the framework 
with the current TestConfiguration. This would cause trouble for 
exceptional cases (as the current JDBC4 testsuite) and if we want to run 
useprocess=false and switch framework. Is this switching of framework 
something we don't need?

> - You have a lot of useful debug statements, but your javadoc doesn't really explain how to turn debug on and off, nor is it clear from the class (e.g. there is not "debug(boolean)" method).
>   

Would mentioning this in the public class documentation do the trick?

    /**
     * Set property used to determine debug mode.
     * Set property to <code>true</code> to enable debug mode.
     * Debug mode can only be enabled/disabled on JVM startup.
     */
    private static final String  DEBUG_PROPERTY     = "derby.tests.debug";
    private static final boolean DEBUG              = new Boolean(
                    PropertyUtil.getSystemProperty(DEBUG_PROPERTY,
                                                   "false")).booleanValue();

> - Your javadoc should be a little more explicit about how the default framework gets set
>   

Noted. For the record, it reads system property "framework".

> - It would be nice to have a helper method that allows subclasses to quickly obtain other properties set by the harness (e.g. so they don't have to do a privileged block every time they want to get a system property)
>   

Are you thinking of a getSystemProperty(key) with a privileged block, or 
a method accessing a "cached" system properties object?

> - I like Andreas' typesafe JDBCClient class, it seems a better approach.
>   

Yes. It should be extended to have information about DataSource classes 
also, or else it would not be sufficent in a JSR 169 (like) environment. 
Some complications here if we want to allow for more than one type of 
DataSource for a given framework (XA, Pooled, Simple, "normal").

--
Kristian

> Thanks,
>
> David
>
>   
>   
>> 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, JDBCClient.java, TestConfiguration.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.
>>     
>
>

[jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.

    [ http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370400 ] 

David Van Couvering commented on DERBY-919:
-------------------------------------------

I think it is great to have base unit test like this, although I agree with Andreas that this should be renamed.  This class is almost solely about obtaining connections using different frameworks, and is very JDBC-specific.  There are plenty of unit tests that have no need for this functionality.

I am not sure how this work integrates with/coincides with the work Andreas did to create a junit test type which allows you to run 'raw' JUnit tests under the harness.  Can you explain?

Here are my general comments...

Javadoc:
- getConnection() - it would be great to say it connects to the default database, instead of "some database", which is a little disconcerting as it sounds somewhat non-deterministic.

- You should document what the defaults are, such as "wombat" for the database name and "APP" for username and password.

- why can't setup() or teardown() automaticlly call resetState() rather than asking the user to do it?  This seems dangerous and highly error-prone.

- when I try to click on a method name, I get a "404" error, although I can scroll directly down to view the method details.  I suspect this is probably just a JIRA bug.

BaseDerbyJUnitTest:

- I don't understand why you set a property for the database name before calling obtainConnection() rather than just passing in the database name to obtainConnection().  It would be good to at least explain the motivation behind this, as at first read it seems a bit odd.  Scanning at the code, it looks like you use db(P_DBNAME) in createBaseDatabaseUrl() where you could just as easily pass the database name in as a parameter

- There are a lot of defaults being setup in a hardcoded fashion in resetState().  It would be better to have a section of static finals at the top with all the default values so that someone looking at this code can tell right away what they are.  Actually, looking at Andreas' TestConfiguration, that is a nice way of doing it . Having it as a separate class also seems to be useful and more coherent.

- You have a lot of useful debug statements, but your javadoc doesn't really explain how to turn debug on and off, nor is it clear from the class (e.g. there is not "debug(boolean)" method).

- Your javadoc should be a little more explicit about how the default framework gets set

- It would be nice to have a helper method that allows subclasses to quickly obtain other properties set by the harness (e.g. so they don't have to do a privileged block every time they want to get a system property)

- I like Andreas' typesafe JDBCClient class, it seems a better approach.

Thanks,

David


> 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, JDBCClient.java, TestConfiguration.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

[jira] Resolved: (DERBY-919) improve pattern for setting up junit tests

Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.

     [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]
     
David Van Couvering resolved DERBY-919:
---------------------------------------

    Resolution: Fixed

Committed revision 386483.  Builds fine.  No impact on derbyall, although Andreas did verify it works, so I did not run any tests.

> 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
>     Assignee: Kristian Waagan
>  Attachments: BaseJUnitTestClasses-v1.tar, BaseJUnitTestClasses-v2.tar, BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, BasicDerbyJUnitTestTest.java, JDBCClient.java, TestConfiguration.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

[jira] Assigned: (DERBY-919) improve pattern for setting up junit tests

Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.

     [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]

Andreas Korneliussen reassigned DERBY-919:
------------------------------------------

    Assign To:     (was: Andreas Korneliussen)

Unassigned since there is currently no activity on this issue

> 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

>
> 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

[jira] Assigned: (DERBY-919) improve pattern for setting up junit tests

Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.

     [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]

Kristian Waagan reassigned DERBY-919:
-------------------------------------

    Assign To: Kristian Waagan

> 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
>     Assignee: Kristian Waagan
>  Attachments: BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, BasicDerbyJUnitTestTest.java, JDBCClient.java, TestConfiguration.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

[jira] Reopened: (DERBY-919) improve pattern for setting up junit tests

Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.

     [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]
     
Andreas Korneliussen reopened DERBY-919:
----------------------------------------


> 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
>     Assignee: Kristian Waagan
>  Attachments: BaseJUnitTestClasses-v1.tar, BaseJUnitTestClasses-v2.tar, BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, BasicDerbyJUnitTestTest.java, JDBCClient.java, TestConfiguration.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

[jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.

    [ http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370710 ] 

Andreas Korneliussen commented on DERBY-919:
--------------------------------------------

Review of BaseJUnitTestClasses-v1.tar:
This patch looks good.

I downloaded the files you submitted, and checked how it would work to change SURBaseTest to extend BaseJDBCTest. This worked very well with. I removed the getConnection() method in SURBaseTest., so that the class would use  the getConnection() method from BaseJDBCTest. Then I successfully ran the tests that extend SURBaseTest as type .junit, both in the embedded framework and in the DerbyNetClient framework.  

Minor comments:
1. In BaseJDBCTestCase class initializer: I think you could print the stack trace for the exception.
2. In TestConfiguration: isVerbose is always set to false.
3. I would like methods to log stuff and print stack traces. You do not have to supply them here, I can add them later since that is my itch.


> 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
>     Assignee: Kristian Waagan
>  Attachments: BaseJUnitTestClasses-v1.tar, BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, BasicDerbyJUnitTestTest.java, JDBCClient.java, TestConfiguration.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

[jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.

    [ 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 DriverManager.
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)
> 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

[jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.

    [ http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370144 ] 

Andreas Korneliussen commented on DERBY-919:
--------------------------------------------

The main idea with this issue was to clean up the exisiting tests which inherit from DerbyJUnitTest, so that they can be run as type .junit.
I have done some work in this area, however it is not completed in because of the additional harness in compatibility suite.

In general, I think junit can be used to write real unit tests as well, not only JDBC-tests. 
I.e I would like to write some tests that tests store functionality using Junit. In such cases, I think I would not like to inherit from a class which provides me with utility functions to get a JDBC connection. Therefore, one should be careful of what we call BaseDerbyJuniTest and DerbyJUnitTest.

I would propose doing the following with BaseDerbyJunitTest
1. Rename it to BaseJDBCTest
2. Maybe provide a setUp() which sets up a connection in the database, using TestUtil.
, then call an abstract method called:
createDataModel()
populateDatamodel()

or  a more general abstract method like: doAdditionalSetup()

In teardown() call abstract methods like:
dropDataModel()
and close the connection.
(or a more general method like doAdditionalSetup)

I think BasicDerbyJunitTest should use TestUtil to get the connection. 

> 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

[jira] Closed: (DERBY-919) improve pattern for setting up junit tests

Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.

     [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]
     
Andreas Korneliussen closed DERBY-919:
--------------------------------------

    Resolution: Fixed

> 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
>     Versions: 10.2.0.0
>  Environment: All
>     Reporter: Andreas Korneliussen
>     Assignee: Kristian Waagan
>      Fix For: 10.2.0.0
>  Attachments: BaseJUnitTestClasses-v1.tar, BaseJUnitTestClasses-v2.tar, BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, BasicDerbyJUnitTestTest.java, JDBCClient.java, TestConfiguration.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

[jira] Updated: (DERBY-919) improve pattern for setting up junit tests

Posted by "Kristian Waagan (JIRA)" <de...@db.apache.org>.

     [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]

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

    Attachment: BaseJUnitTestClasses-v1.tar

Another go at establishing base classes for JUnit tests - 'BaseJUnitTestClasses-v1.tar' (tar contains 4 files, extract in trunk).
Implementation is a result of the comments received and classes submitted to this Jira issue.
The implementation is just a first go, it is not complete. When it (hopefully) is committed, I will create a Jira issue for tracking improvements and bugs related to the base classes for JUnit tests.
I have tried using BaseJDBCTestCase in some tests, and for my current use it has been sufficient and working. It will have to be extended pretty soon.

I would appreciate if someone had a look at this pretty quick, and that a committer committed it as soon as it is approved.

A few comments:
* no support for getting connections through DataSource yet.
* no DataSource class name included for the JCC client.
* exception handling in BaseJDBCTestCase.loadJDBCDriver() not optimal (initCause not available in Java 1.3).
* methods in BaseJDBCTestCase are static so that for instance TestSetup classes can use them.

> 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
>     Assignee: Kristian Waagan
>  Attachments: BaseJUnitTestClasses-v1.tar, BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, BasicDerbyJUnitTestTest.java, JDBCClient.java, TestConfiguration.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

[jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.

    [ http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370624 ] 

David Van Couvering commented on DERBY-919:
-------------------------------------------

Wow, you're working late - 12:14 am.  :)

Well, one could argue that we don't "need" anything except the Derby network client and embedded drivers.   If it's your itch to also support the DB2 JCC driver, go ahead, but your first implementation of this *could* include just support for the Derby JDBC embedded and network drivers.

> 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, JDBCClient.java, TestConfiguration.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

[jira] Closed: (DERBY-919) improve pattern for setting up junit tests

Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.

     [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]
     
Andreas Korneliussen closed DERBY-919:
--------------------------------------


Pattern has been improved by introducing the new BaseTestCase and BaseJDBCtestCase classes.

> 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
>     Assignee: Kristian Waagan
>  Attachments: BaseJUnitTestClasses-v1.tar, BaseJUnitTestClasses-v2.tar, BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, BasicDerbyJUnitTestTest.java, JDBCClient.java, TestConfiguration.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

[jira] Updated: (DERBY-919) improve pattern for setting up junit tests

Posted by "Andreas Korneliussen (JIRA)" <de...@db.apache.org>.

     [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]

Andreas Korneliussen updated DERBY-919:
---------------------------------------

    Attachment: JDBCClient.java
                TestConfiguration.java

Just attaching two files which provides:
1. A TestConfiguration 
2. A type safe enum for JDBC Clients (framework)

I think these could be used along with  DerbyJUnitTest and/or BaseDerbyJUnitTest. These classes could have access to a TestConfiguration object, and use it to get the correct framework, database name etc.

I think BaseDerbyJUnitTest.getConnection() should not be dependent on an activeFrameWorkId attribute. 
Instead, it should simply return the connection for the configured framework. If the user need to get a connection to another framework, they should supply the framework as a parameter to an overloaded getConnection() method.


> 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, JDBCClient.java, TestConfiguration.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

[jira] Commented: (DERBY-919) improve pattern for setting up junit tests

Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.

    [ http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370742 ] 

David Van Couvering commented on DERBY-919:
-------------------------------------------

Comments look positive.  I'll take a quick look and will either commit or provide comments.

> 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
>     Assignee: Kristian Waagan
>  Attachments: BaseJUnitTestClasses-v1.tar, BaseJUnitTestClasses-v2.tar, BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, BasicDerbyJUnitTestTest.java, JDBCClient.java, TestConfiguration.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