commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ringo.des...@mediagenix.com
Subject RE: [lang] Unit test coding conventions?
Date Fri, 05 Jul 2002 12:39:29 GMT
Hello,

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

Agreed, the setUp and tearDown methods should be used for this.

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

Still, don't you find it annoying that the first case could fail, that you
fix it and on the subsequent test run another case fails? If you have a test
method per case, you see *all* failures at once. This gives you better
insight on what you have to do to fix the set of failures instead of
focusing on one case at the time. More than once, I gained time having a
test method per case setup.

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

BTW, there are 4 different Strings test classes that test part of the
Strings API. Shouldn't we put all the tests in the StringsTest class?

> 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 :)

What name would setTarget deduce from the class argument? The class name? if
you want that, invoke suite.setName(Strings.class.getName()). The setName
method gives you the most flexibility.
And out of experience, the JUnit developers are very restrictive on the
changes that go into the core JUnit. This has its advantages and
disadvantages...

Ringo

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message