JUnit, writing todo tests...

[Phillip Lord]

Does anyone know if its possible to write "todo" tests with Junit?
That is tests which are expected to fail because they have not been
implemented yet, but will not actually show up as a failure.

The perl test harness implements this and it's very useful because you
can use it to mark up tests for functionality that you are going to
implement but have not yet.

Cheers

Phil

 

[Giorgio Franceschetti]

Does anyone know if its possible to write "todo" tests with Junit?
That is tests which are expected to fail because they have not been
implemented yet, but will not actually show up as a failure.

The perl test harness implements this and it's very useful because you
can use it to mark up tests for functionality that you are going to
implement but have not yet.

Cheers

Phil

Hope this can help.
Bye,
Giorgio

public class OoClassTest extends TestCase {

public OoClassTest(java.lang.String testName) {
super(testName);
}

/** Test of "method"method, of class yourpackage.OoClass */

public void testMethod() {
System.out.println("testMethod");
fail("To be implemented.");
}

 

[Phillip Lord]

Giorgio> Hope this can help. Bye,
Giorgio> Giorgio

Giorgio> public class OoClassTest extends TestCase {

Giorgio> public OoClassTest(java.lang.String testName) {
Giorgio> super(testName);
Giorgio> }

Giorgio> /** Test of "method"method, of class
Giorgio> yourpackage.OoClass */

Giorgio> public void testMethod() {
Giorgio> System.out.println("testMethod"); fail("To be
Giorgio> implemented.");
Giorgio> }



This isn't really what I want, as it will always fail. I want to JUnit
to not print out a failure, but to ignore the test until the
functionality has been implemented.

I guess I can just do

public void todotestMethod()
{}

which will mostly work.

Cheers

Phil

 

[Pete Gieser]

What I've done in the past is to put a date check into the test. If the
"run" date of the test is in the future, it passes automatically. Otherwise
it runs the actual test. i.e.,

public void testSomething() {
if (runDate.isInTheFuture()) {
assertTrue(true);
} else {
assertTrue(somethingAspect);
}
}

Pete

 

[Scott Ellsworth]

What I've done in the past is to put a date check into the test. If the
"run" date of the test is in the future, it passes automatically. Otherwise
it runs the actual test. i.e.,

public void testSomething() {
if (runDate.isInTheFuture()) {
assertTrue(true);
} else {
assertTrue(somethingAspect);
}
}

I have done something similar, but rather than a fixed date, I use a
system property.

If you set com.alodar.foo.disableUnwrittenTests to true, then the tests
are stubbed out, and if you do not, then the tests fail. I can then
have a nightly build process run both sets of tests.

public void testSomething() {
if (System.getProperty("com.alodar.foo.disableUnwrittenTests", "false").equals("true")){
assertTrue(true);
} else {
assertTrue(somethingAspect);
}
}

One could get fancy, and put collections of stories together into a
release package, which is then tested against. This kind of goes
against the XP way, which would require only those tests I am planning
on implementing for this iteration to be written. That said, I find it
very convenient to write certain tests when I am thinking about a given
set of functionality.

For example, if I am writing a general formula parser, I will probably
be happiest if I write down all of the test cases I eventually want
while I am developing the "2+2" case I want to have pass in the first
pass. On a project where the feature set is not negotiable, but the
delivery date is, this can be very convenient.

Scott