db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Embretsen <John.Embret...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-934) create a set of JUnit tests for Scrollable Updatable Resultsets
Date Wed, 08 Feb 2006 20:12:05 GMT
Wednesday, February 8, 2006, 8:41:20 PM CET, David W. Van Couvering wrote:

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

Ah, I didn't think of the suite files. Thanks!

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

Sure, either way is fine with me once the new junit type is introduced.

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

That's what I was hoping to avoid ;) Though I guess it's not that big of
an effort. Anyway, let's deal with that when the need arises. I guess it
will take quite some time until a large amount of the tests are
converted to type junit anyway...


-- 
John


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


Mime
View raw message