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.
David
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?
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
