Return-Path: 
 <harmony-dev-return-3024-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org
Received: (qmail 92554 invoked from network); 13 Jan 2006 16:58:07 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 13 Jan 2006 16:58:07 -0000
Received: (qmail 58474 invoked by uid 500); 13 Jan 2006 16:58:02 -0000
Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org
Received: (qmail 58351 invoked by uid 500); 13 Jan 2006 16:58:01 -0000
Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:harmony-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:harmony-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:harmony-dev@incubator.apache.org>
List-Id: <harmony-dev.incubator.apache.org>
Reply-To: harmony-dev@incubator.apache.org
Delivered-To: mailing list harmony-dev@incubator.apache.org
Received: (qmail 58340 invoked by uid 99); 13 Jan 2006 16:58:01 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jan 2006 08:58:01 -0800
X-ASF-Spam-Status: No, hits=1.4 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.71 is neither permitted nor
 denied by domain of geir@pobox.com)
Received: from [64.74.244.71] (HELO chi.mobile-health-diary.com)
 (64.74.244.71)
    by apache.org (qpsmtpd/0.29) with SMTP; Fri, 13 Jan 2006 08:57:59 -0800
Received: (qmail 20127 invoked from network); 13 Jan 2006 16:57:38 -0000
Received: from ool-43560634.dyn.optonline.net (HELO ?192.168.1.100?)
 (geir@67.86.6.52)
  by b014.internal.mobile-health-diary.com with SMTP;
 13 Jan 2006 16:57:38 -0000
Message-ID: <43C7DBFE.7040101@pobox.com>
Date: Fri, 13 Jan 2006 11:57:34 -0500
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: Test suite layout
References: 
 <OFC4ACA33D.81511539-ON802570F4.0033370C-802570F4.0035E4EA@uk.ibm.com>
 <43C63D19.60603@gmail.com> <43C64FBC.3050400@pobox.com>
 <43C68A44.7020706@gmail.com>
In-Reply-To: <43C68A44.7020706@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N



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