On Wed, 2004-04-28 at 18:50, Archie Cobbs wrote:
> David P Grove wrote:
> > > IIRC the biggest problem with using JUnit is that it depends of rather 
> > > advanced JVM features; like reflection.
> > 
> > Sorry if this is an ignorant question, but is this really an issue?  I'd 
> > always assumed (without actually checking) that most (all?) of the VMs 
> > being used by classpath developers implement reflection.  If this is the 
> > case, then maybe making reflection a pre-req for being able to run mauve 
> > wouldn't be an issue.  It's hard to run very much Java code these days 
> > without running into some use of reflection by the application.
> 
> I inferred the problem to be that reflection is one of the things
> we want to test, so we shouldn't be relying on it for the test itself.
> Of course, if reflection doesn't work, then the test will probably
> still fail :-) But it may make it harder to track down the real problem.
> 
> All in all, it's probably not a major deal... Perhaps there could be
> a small set of basic reflection tests that didn't use JUnit too.

Junit does not require reflection if used in a particular manner.  See
http://junit.sourceforge.net/doc/testinfected/testing.htm.  But it's
probably easier all around if reflection is allowed.

JUnit supports two ways of running single tests: 
      * static
      * dynamic
In the static way you override the runTest method inherited from
TestCase and call the desired test case. A convenient way to do this is
with an anonymous inner class. Note that each test must be given a name,
so you can identify it if it fails. 
TestCase test= new MoneyTest("simple add") {
    public void runTest() {
        testSimpleAdd();
    }
};