JUnit, writing todo tests...

Discussion in 'Java' started by Phillip Lord, Feb 9, 2004.

  1. Phillip Lord

    Phillip Lord Guest

    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
    Phillip Lord, Feb 9, 2004
    #1
    1. Advertising

  2. Phillip Lord wrote:
    >
    >
    >
    > 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.");
    }
    Giorgio Franceschetti, Feb 10, 2004
    #2
    1. Advertising

  3. Phillip Lord

    Phillip Lord Guest

    >>>>> "Giorgio" == Giorgio Franceschetti <> writes:

    Giorgio> Phillip Lord wrote:
    >> 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> 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
    Phillip Lord, Feb 11, 2004
    #3
  4. Phillip Lord

    Pete Gieser Guest

    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

    "Phillip Lord" <> wrote in message
    news:...
    > >>>>> "Giorgio" == Giorgio Franceschetti <>

    writes:
    >
    > Giorgio> Phillip Lord wrote:
    > >> 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> 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, Feb 11, 2004
    #4
  5. In article <eOwWb.151271$>,
    "Pete Gieser" <> wrote:

    > 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
    Scott Ellsworth, Feb 12, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jan
    Replies:
    0
    Views:
    3,672
  2. Stephen Riehm
    Replies:
    2
    Views:
    694
    Stephen Riehm
    Nov 3, 2004
  3. Rafal Majda

    JUnit - description of tests

    Rafal Majda, Apr 6, 2005, in forum: Java
    Replies:
    4
    Views:
    2,226
    Darryl Pierce
    Apr 11, 2005
  4. Replies:
    8
    Views:
    877
  5. Christopher Benson-Manica

    Reflection in JUnit tests

    Christopher Benson-Manica, Jul 7, 2006, in forum: Java
    Replies:
    12
    Views:
    5,446
    Christopher Benson-Manica
    Jul 11, 2006
Loading...

Share This Page