commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject RE: [lang] Unit test coding conventions?
Date Fri, 05 Jul 2002 13:07:10 GMT
S'all opinion. Even in Java there's more than one way to do it. Usually
only 2 or 3 ways though. :)

Hen

On Fri, 5 Jul 2002, Rand McNeely wrote:

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


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