Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42387130.9030403@d-haven.org>
Date: Wed, 16 Mar 2005 12:47:28 -0500
From: Berin Loritsch <bloritsch@d-haven.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
CC: "'Apache Directory Developers List'" <directory-dev@incubator.apache.org>
Subject: Re: Tests naming
References: 
 <777DDD941E46D41181B300508BAE014F0DDD41AA@synntm8.mtl.optimumgroup.com>
In-Reply-To: 
 <777DDD941E46D41181B300508BAE014F0DDD41AA@synntm8.mtl.optimumgroup.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Tenc�, Vincent wrote:

>I started looking at removing Snacc dep in asn1/ber and came accross this
>test I have to change. But I have no clue what it is doing:
>
>    public void testAbandonMessage() throws Exception
>    {
>        AbandonRequestImpl request = new AbandonRequestImpl( 1 ) ;
>        request.setAbandoned( 3 ) ;
>        decode( request ) ;
>        roundTripTest( request ) ;
>        assertFalse( tlvList.isEmpty() ) ;
>    }
>
>I'll take the opportunity to discuss test methods naming. The issue with
>this sort of naming is that it doesn't help if you don't know the code - I
>hope it's clear at least to someone who knows the code ;-) - so you lose a
>the power of test as a documentation mechanism. Basically I'm stuck, not
>knowing what the code does nor what the test is trying to prove.
>
>The approach I favor is to name test methods so that they describe the
>intention of the test, rather than the method or the data under test. For
>example, if I'm writing a test for a decorator that caches compiled java
>classes from script, instead of writing tests like:
>
>testLoadClass()
>testLoadClassTwice()
>
>I would favor:
>
>testClassesAreRetrievedFromCacheIfScriptHasNotChanged()
>testClassesAreReloadedIfScriptWasChanged
>
>I have found that this practise helps a lot in documenting tests and code,
>for others as well as yourself when you're reading your tests later on. It
>also helps clarify what you're trying to achieve when you're writing the
>test. It keeps you focused and helps think of other test cases you're not
>covering.
>
>I'd like to hear what you guys have to say on this, and discuss the adoption
>of such a practise for the project. When we're at it, I'd like to open a
>discussion on the testing practices we want to enforce.
>
>Cheers,
>-- Vincent
>
>  
>

I agree to a certain extent, although tracability back to the method we 
are testing is helpful to me.
I tend to favor a variation on what you do.  I use the method name 
followed by descriptions.
For a method named "loadClass" I would do something like this:

testLoadClass() // normal critical path
testLoadClass_fromCacheIfScriptNotChanged()
testLoadClass_noClassNameProvided()
testLoadClass_reloadIfScriptChanged()

Each testing a different specific aspect of the method.  I will have a 
different test for each permutation
or branch I have to ensure works properly.  If there are branches I 
can't excersize from the test harness
then it is dead code and needs to be removed.  The approach I use gives 
both the tracability to the
method and the clarity you desire.  Just my 2 cents.