Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Aside: some folks add the additional (sub)rule that the test should first fail with a meaningful error message. – DNA Jul 4 '13 at 21:25
up vote 11 down vote accepted

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

That's why you 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.

share|improve this answer
Won't I be showing that when I write the first test that fails without changing the impl? – Daniel Kaplan Mar 9 '13 at 0:19
I thought you said that you want your first test to pass. – Robert Harvey Mar 9 '13 at 0:20
It's not about want, I just happened to write a few tests that say, "given...when...then return null" and my production code implementation returns null. My ide creates blank impls with return null; as a stub for me. – Daniel Kaplan Mar 9 '13 at 0:22
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 Mar 9 '13 at 0:32
@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 Mar 9 '13 at 7:48

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.

share|improve this answer
+1 : Excellent, so much truth spoken in such few words.... – mattnz Mar 9 '13 at 8:05
+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 Mar 9 '13 at 10:26
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 Mar 9 '13 at 17:52
@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 Mar 9 '13 at 18:13
@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 Mar 11 '13 at 20:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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