db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for Scrollable Updatable Resultsets
Date Wed, 08 Feb 2006 19:41:20 GMT
It seems to me one quickly discovers that a test is junit-ified if it 
fails when you try to run it as a .java.  It will also help that the 
suite files will describe it as a .junit.

To me this small annoyance is better than having to maintain two 
separate hierarchies and in some cases splitting up a coherent set of 
tests into two areas.

We could also write a tool that scans all the classes in a directory and 
reports which ones extend a JUnit class and which ones don't.


John Embretsen wrote:
> Wednesday, February 8, 2006, 7:32:12 PM CET, David W. Van Couvering wrote:
>>I am also a bit uncomfortable with a separate subdirectory for junit 
>>tests.  Is there a specific reason for this segregation?  If we have a 
>>new test type, .junit, why can't that be sufficient to distinguish 
>>between a JUnit test and an "old-style" test?  I'd like to reuse the 
>>existing subdirectories like lang and jdbcapi rather than create a 
>>mirror of subdirectories, or even a completely orthogonal set of 
>>subdirectories, under junitTests.
> Here is a link to a couple of messages to derby-dev regarding this
> decision: http://tinyurl.com/bvde2  (Nabble)
> The reason for doing it this way was basically that at that time
> (October last year), this was our best option with regards to separating
> JUnit tests from other tests. Otherwise it may quickly become difficult
> to keep track of which tests have been converted to (or created for)
> JUnit.
> Does the new junit type really eliminate this "need"? The files are still
> .java files; the type is just used by the harness to determine the java
> executable it should use to run the test. Or am I missing something
> here?

View raw message