commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [lang] Unit test coding conventions?
Date Fri, 05 Jul 2002 12:18:28 GMT
My current complaints with the structure of StringsTest is that I don't
like the extraction of the constant-variables to the top. FOO/BAR etc.
This feels like a rare case in which it actually makes the code harder to
read, without gaining much of an advantage.

I am against a test method only testing one case, but am for a test method
testing only one target on the tested-class. Check CharSetTest where I am
currently doing 5 tests per tested-class method.

I'm happy with a test testing a group of methods that are related, but I'm
not married to it.

The build.xml's currently make us add a class each time. I'd like to be
able to have some ant task which allows me to say:

ant test strings

and it automatically finds StringsTest and runs that. Pretty sure my ant
skills aren't up to the task though. Okay, the pun was slightly intended.

Dunno if JUnit would allow it, but would be nicer to say
suite.setTarget(Strings.class) rather than setName("Strings test"). I need
to grab the JUnit Javadoc :)


On Fri, 5 Jul 2002 wrote:

> Hello,
> I want to write some additional unit tests for the Strings class as was
> listed in the todo's for an 1.0 release. I looked at the StringsTest class
> and noticed that there are not a lot of test methods, but each of the test
> methods contains multiple assert statements. Personally, I don't like this
> approach, since a test method will fail on the first failing assertion. The
> following assertions will not be executed. I would like to have a test
> method for each separate case, which means that you will get a n-1 relation
> between test methods and production code methods.
> How about you?
> Ringo
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message