Re: On "TDD theory"

J Krugman wrote: 
In <db3qeg$7u2$1@xxxxxxxxxxxxxxxxx> J Krugman <jkrugman345@xxxxxxxxxxxx> writes:


...I only recently learned
about the notion of starting out with a *failing* test, and I
confess that I have only a tenuous grasp of what this really means
(it is too trivial to write a failing test, so there must be more
to it than the name suggests).



Just to clarify what I meant by the last line, the following is a
trivial failing test which doesn't seem to me terribly useful:

import junit.framework.TestCase;

public class MyUselessTest extends TestCase {
  public void testWhoopee() throws Exception {
    fail("Are we having fun yet?");
  }
}

I don't see why this is a particularly useful starting point.
Hence I conclude that what constitutes the proverbial initial
"failing test" has to be something *more* than *simply* a test that
fails.  I have not been able to find a sufficiently articulate
answer to this question.  (I.e., everyone seems to assume that the
definition of an "initial failing test" is self-evident, but it is
not so to me.)

jill


when we say 'start off with a failing test' we don't mean write a test that does nothing but fail, like yours.

We mean write a test that uses the class(es) you are about to develop/enhance.

So, lets pretend we have a Whoopee noise generator.

we start with a test

public void testWhoopeeNoise() {
  MockSoundOutputStream mockSpeaker = new MockSoundOutputStream();

  WhoopeeGenerator whoopeeGen = new WhoopeeGenerator();

  whoopeeGen.makeANoise();

  assertTrue("no noise!", mockSpeaker.wasNoiseMade() );
}


Now, at this point, the test case doesn't even compile, because we haven't got a class called WhoopeeGenerator, nor the MockSoundOutputStream.

This is a failing test, because it doesn't compile.

So we create the necessary classes and the stub implementation of the required methods (e.g WhoopeeGenerator.makeANoise() ).

Still the test fails, cause we haven't actually implemented the classes, we just create empty stubs.

Once we implement just enough of the two classes to make the test pass, we can move onto the next test.

Another good reason for having the test first and having it fail first, because we haven't implemented the necessary code, is to help safe guard ourselves against dodgy tests or unexpected successes.

For example, if we wrote the test first, then wrote the necessary WhoopeeGenerator classes etc, before we even ran the test, we could have easily have made a mistake within the test code which means the test passes regardless of the production code. By Writing the test first, then running it, we expect it to fail as we haven't implement enough to make it pass. If it doesn't fail as expected, then we need to find out why.

We all get caught out with this, if we don't run the test often enough.

Sometimes test will pass because we are using classes that have already been implemented in a way to make the test pass, but because we were the one's who wrote the classes, we didn't know. But without expecting the test to fail, we would not have seen this and blindly carried on.



.

Relevant Pages

  • Re: Both headlights failing at the same time???
    ... Blue lights are crap. ... having both fail at exactly the same time was a bit of a coincidence. ... and shouldn't be failing together. ... blowing, not the high beam, because I rarely use the high beam. ...
    (rec.autos.makers.honda)
  • Re: A Type II Camp?
    ... II adults who were either newly diagnosed or failing to follow their ... doctor's treatment plan what elements of a program would you include? ... I would simply refuse to do it because I fail to see how that sort of thing ... to fail, camp or no camp. ...
    (alt.support.diabetes)
  • Re: copy error
    ... each time through loop ... You are inspecting $! ... along the line, something that "copy" does is failing with that message, ... but the "copy" itself does not fail, ...
    (comp.lang.perl.misc)
  • Re: JSON without AJAX
    ... > Randy Webb wrote: ... > A has a 10% chance of failing, and B has a 90% chance of failing. ... prerequisites it demands, it will -never- fail), or we still use it IF ...
    (comp.lang.javascript)