[Biojava-l] Unit tests

Jason Stajich jason@chg.mc.duke.edu
Wed, 9 May 2001 19:13:16 -0400 (EDT)


We are preparing (slowly) to setup nightly builds and unit tests can be
incorperated into that so we can stay on top of things.  We may need
volunteers from each language project to setup their build(s) properly.
Details as Chris and I get things on-line.

-Jason

On Wed, 9 May 2001, Matthew Pocock wrote:

> Testing would have caught several of our recurent bugs. Long over-due.
> 
> Parallel source trees get my vote. Munging test cases under the src/ 
> tree is an over-my-dead-body option (but then you can always depose me). 
> JUnit is fine by me and seems to be the defacto standard. We can let the 
> classloader do the tree merging magic necisary to test private API, but 
> as Thomas said, most of the time you will be wanting to validate that 
> implementations conform to interfaces. Does JUnit allow you to define 
> tests for an interface and then apply that to a collection of objects 
> that implement it? That would be ideal for us.
> 
> Now we just need to avoid writing object implementations to pass test 
> cases - it's a pity that we can't make the implementations unaware of 
> what tests they will need to pass to be valid...
> 
> M
> 
> Thomas Down wrote:
> 
> > On Wed, May 09, 2001 at 05:23:44PM +0100, Simon Brocklehurst wrote:
> > 
> >> o Location of test classes - they need to be inside packages so that you can
> >> write tests for package-private classes
> > 
> > 
> > 
> > While it's true that you need to put your test classes in the same
> > Java package in order to test private stuff, that doesn't
> > necessarily mean they have to live in the same directory tree.
> > 
> > We can have a structure like
> > 
> >    src/
> > 
> >       org.biojava.bio.foo.PrivateImplementation.java
> > 
> >    test/
> >    
> >       org.biojava.bio.foo.TestCases.java
> > 
> > 
> > That keeps a nice, clean, distinction between `real' code and
> > tests. 
> > 
> > I'd also tend to argue that (most of the time, anyway) tests
> > should be testing the behaviour of public API -- what goes
> > on behind the scenes is, by definition, private, and if this
> > changes it doesn't mean there's a bug, so long as all the public
> > API still behaves as expected.  (Although in practice, yes,
> > private tests might be useful in a few of the more complex
> > cases).
> > 
> >    Thomas.
> > _______________________________________________
> > Biojava-l mailing list  -  Biojava-l@biojava.org
> > http://biojava.org/mailman/listinfo/biojava-l
> 
> 
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
> 

Jason Stajich
jason@chg.mc.duke.edu
Center for Human Genetics
Duke University Medical Center 
http://www.chg.duke.edu/