"Aaron M. Renn" <[EMAIL PROTECTED]> writes:
> Isn't this basically the one test per file approach?
Yes.
> I would like to be able to have a given java class execute more than
> one test.
Picky. Picky. Picky. :)
I tend to think a one test per class approach is a good way to go --
it's simple, elegant, and it forces people to write tests which are
small and to the point. With such fine granularity, I believe it
would be easier to keep track of what work needs to be done on the
testsuite.
If you look at a "test" as any given set of smaller tests which test
parts of one large "thing", and (generally) each succeeding small test
relies upon the success of the previous small test, you could
structure say, your SimpleURLTest as:
test() {
dostuff1
if (stuff1 fails)
return new Fail(SimpleURLTest: part stuff1 failed)
dostuff2
if (stuff2 fails)
return new Fail(SimpleURLTest: part stuff2 failed)
return new Pass(SimpleURLTest passed)
}
So SimpleURLTest would be a single test (as far as the framework is
concerned), but it could fail in multiple places, for different
reasons.
There's also the option of modifying test() along the lines:
public Result[] test();
Result objects would change to include a test name, and a result.
Or we could do something along the lines
public interface gnu.test.Test {
public void test(Callback c);
}
In this case, a test would do stuff like
"c.addResult(new Passed("foobar"))" or "c.Passed("foobar")" as each
test was completed.
Comments?
(I currently think the SimpleURLTest example is the best way to go.)
> Also, have you run this by the Cygnus folks?
Not yet. I wanted to get our groups' opinions first.
--
Paul Fisher * [EMAIL PROTECTED]
