Paulex Yang wrote:
Geir Magnusson Jr wrote:
Tim Ellison wrote:
What we've tended to do, internally, is to name the testcases after the
type they are testing, so all unit tests for java.io.File are put into a
tests package ending with java.io in a type called FileTest that extends
the junit.framework.TestCase.
Yes - that's the canonical way. Put it the the same package as what
you are testing, and then use a common name pattern to make it easy to
configure ant or maven with a wildcard.
*/*/*Test
We would have written it as java.io.tests, but the java.<whatever>
namespace is reserved, so the formula is simply
<package>.<type> -> org.apache.harmony.tests.<package>.<type>Test
Ug - then you have the problem of not being in the namespace as what
you are testing.
THat's why people use parallel trees - so your test code is physically
separate but you have freedom of package access.
This makes it clear what is being tested, and where to add new tests
etc.
So would
test/org/apache/harmony/io/TestFoo.java
(to test something in org.apache.harmony.io, and arguable to test the
Foo.java class in there. (or TestFoo.java - it's early - no coffee yet)
Simiarly
test/java/util/TestMap.java
Then within the test class itself the methods are named after the method
under test, with a familar JNI-style encoding, so we have things like:
org.apache.harmony.tests.java.io.FileTest contains
public void test_ConstructorLjava_io_FileLjava_lang_String() {
...
}
and
org.apache.harmony.tests.java.lang.FloatTest contains
public void test_compareToLjava_lang_Float() {
...
}
...or whatever the convention is for JUnit. I think that's one of the
nice things about TestNG, is that it's annotated, so you have the
freedom there.
Agree with you that annotation is great, and I just wish JUnit 4 can be
released soon
(check out an intro here
http://www-128.ibm.com/developerworks/java/library/j-junit4.html)
But even if we have more freedom, I think some convention is still
*precious*, this name contract between test and method is one example.
At least in Eclipse, I can easily find the test case for some certain
method simply by ctrl+o and key in "test_"+method name, that's natural
and easy, and if tests failed, I can see which method is wrong in just
one glance, so personally I'm willing to pay the price to convention 8-)
Agreed, although I prefer TestGet, TestFoo, etc...
