directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Tests naming
Date Wed, 16 Mar 2005 17:47:28 GMT
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:
>I would favor:
>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
>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.
>-- 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

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.

View raw message