commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rand McNeely" <rand_mcne...@yahoo.com>
Subject RE: [lang] Unit test coding conventions?
Date Fri, 05 Jul 2002 13:03:11 GMT
Well this is just great...  I had never used JUnit until I started
contributing to this project and after I look at StringTest to figure
out how it is supposed to work, now I am told that's not the way to do
it :)


> -----Original Message-----
> From: ringo.desmet@mediagenix.com [mailto:ringo.desmet@mediagenix.com]
> Sent: Friday, July 05, 2002 7:39 AM
> To: commons-dev@jakarta.apache.org
> Subject: RE: [lang] Unit test coding conventions?
> 
> 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>


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