8

Uncle Bob's rules for TDD are specified here.

  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

But, is it ok to write a bunch of tests that pass as soon as the test compiles? For example, a test that asserts null and the default impl of a method I'm testing returns null. Am I doing something wrong by doing this? Should I skip to the first test that will fail or is it ok to write tests that automatically pass first?

Improve this question
1
  • Aside: some folks add the additional (sub)rule that the test should first fail with a meaningful error message.
    – DNA
    Commented Jul 4, 2013 at 21:25

2 Answers 2

Reset to default
17

No, because it is possible to write a test that inadvertently passes when it should actually fail.

That's why you must make it fail first, so that you can demonstrate transitioning from a failed state to a passed state where you're testing the actual functionality that you want, rather than having a bogus test that passes and makes you think that your code actually works, when in fact it doesn't.

Improve this answer
7
  • Won't I be showing that when I write the first test that fails without changing the impl?
    – Daniel Kaplan
    Commented Mar 9, 2013 at 0:19
  • I thought you said that you want your first test to pass.
    – Robert Harvey
    Commented Mar 9, 2013 at 0:20
  • 3
    Throw an exception as placeholder, that way it'll always fail (unless you test for this specific exception). If you return null as a placeholder, but it's also valid implementation, you've already broken the rules.
    – Jeroen Vannevel
    Commented Mar 9, 2013 at 0:32
  • 1
    @tieTYT: If the very first test on a method happens to test for the stub-implementation that your IDE creates for a method, I would not worry too much. The initial compilation failure due to the missing method is also a test failure.
    – Bart van Ingen Schenau
    Commented Mar 9, 2013 at 7:48
  • 1
    @BartvanIngenSchenau: Not really. Without compilation, the test cannot be executed at all. You cannot get a "red" result from a test that never runs.
    – Robert Harvey
    Commented Mar 9, 2013 at 18:13
19

It depends.

If you are writing software to solve a business problem or produce a useful tool, then yes, you are allowed to write a test that passes automatically.

If, on the other hand, you are writing software in order to perform a religious observance at the First Denominational Church of TDD, then no, you are not allowed to do that. And you should probably take a moment of self-flagellation for even asking the question.

Improve this answer
6
  • 2
    +1 : Excellent, so much truth spoken in such few words....
    – mattnz
    Commented Mar 9, 2013 at 8:05
  • 3
    +1, great answer, I have to remember this for every case where one asks "do I have to follow some evangelists rules strictly"
    – Doc Brown
    Commented Mar 9, 2013 at 10:26
  • 3
    TDD is so unintuitive I want to make sure I'm strictly following the practice before I decide if the practice is worth following. If I took the attitude of, "This seems silly and I probably don't need to worry about it" I wouldn't have attempted TDD in the first place. Even if I never strictly practice TDD, I think there's a lot of value in knowing how to strictly practice it.
    – Daniel Kaplan
    Commented Mar 9, 2013 at 17:52
  • 1
    @tieTYT: It will be less unintuitive if you think of TDD as part of your design process. Because units tests require testable methods, the practice of creating the test first shapes the API and influences the way you write your code, in positive ways.
    – Robert Harvey
    Commented Mar 9, 2013 at 18:13
  • 1
    @tieTYT : Many current best practice methodologies were created by an evangelical 'big bang' (usually in some university by some academic who had obviously failed high school statistics and could not grasp the simple concept that 50% of developers are below average) and subsequently evolved into what is now called best practice. Those that failed to evolve, died (Darwinism at it's best). TDD is still evolving. Further TDD is about as easy and practical to retrofit to existing applications as turning an F1 race car into a family people mover.
    – mattnz
    Commented Mar 11, 2013 at 20:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.