Re: Using Unit Tests for bug tracking

From: Holger Hoffstätte (holge..izards.de)
Date: Sat Dec 21 2002 - 16:21:07 EST

  • Next message: Andrus: "Re: Using Unit Tests for bug tracking"

    Andrus wrote:
    > [JUnit for bug tracking]

    The original idea is to have a red/green distinction and really nothing in
    between; all tests must succeed all the time, and you fix a problem as
    soon as a test fails. This is one of the things that many people -
    understandably! - don't like about JUnit: it doesn't allow for 'slack',
    even when it's necessary or meant well, like in your example. I'm not
    aware of any solution to this problem, since exactly this slack will then
    usually lead many projects into their code-'n-fix death spiral when the
    participants don't have the necessary discipline. It's really difficult.

    > I can probably hack something like that into CayenneTestCase superclass. I
    > was just wondering if there is a JUnit solution to it. Or is this against
    > their philosophy?

    The JUnit FAQ explains something along this line (I think) in item 4.9
    ("What's the difference between a failure and an error?") but I'm not sure
    if this is what you're after? I've used the expected failures quite often
    myself, but never for bug tracking, more as a kind of safety net for
    unreachable code or prevention for regression. But we could certainly try
    to use failures for "soft" and assertions for "hard" errors, like in the
    example given in the FAQ. This would also mean that all tests would have
    to conform to this failure/error raising behaviour.
    Hm..thinking of an example. Let's try!

    QueryHelper.selectObjectForId(ObjectId) is supposed to return a
    SelectQuery but will fail with an NPE if the passed ObjectId is null
    (sorry for the obvious example ;). I stumble over this and write a test
    which is expected to fail:

    // I never declare my tests to throw anything
    void testSelectObjectForIdNullArg()
    {
        try
        {
            SelectQuery q = QueryHelper.selectQueryForObjectId(null);
        }

        // bad
        catch (NullPointerException npe)
        {
            fail("bad NPE! fix me!");
        }

        // better: the expected behaviour
        catch (IllegalArgumentException iae)
        {
            // all OK - nothing to be done
        }
    }

    Is this about what you had in mind?

    Holger



    This archive was generated by hypermail 2.0.0 : Sat Dec 21 2002 - 16:21:23 EST