[Biojava-l] Unit tests

Matthew Pocock mrp@sanger.ac.uk
Wed, 09 May 2001 17:43:34 +0100


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