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