Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

4
  • 1
    "Whether or not you actually write each test a minute before you write a routine or a minute after is actually slightly less important." - Except that once you've come this far, there is zero cost to doing it first, and there is the benefit of knowing your test is correct because it will fail when your code is not written. Write the code afterwards and you can never have that reassurance. Commented Aug 2, 2012 at 10:26
  • 2
    There is a slight subtlety here. Usually, TDD advocate tell you to write the test before the method it calls even exists, so that it trivially fails. But this only works for scripting languages; if the test doesn't even compile! That gives you no reassurance at all that it will actually catch an error if it ever creeps in. The important thing is that you see the test fail meaningfully, i.e. catching an error in the actual code. If your language makes this difficult, best practice is to deliberately simplify the code (or back out the fix you just wrote) to verify that the test actually fails. Commented Aug 2, 2012 at 10:34
  • 1
    In those languages, you can code the method but still not implement it. That's what NotImplementedExceptions are for. Even in scripted languages, it's only the first test that should fail because the method doesn't exist; each subsequent test should fail because you've only written the simplest code possible to make the previous tests pass. Commented Aug 2, 2012 at 11:09
  • @Kilian Foth: I didn't say I think the code is loosely coupled. I said I think the code is testable. And it's possible to imagine or even check automatically if code is testable. If code is a mess is a different problem. TDD might help you have programmers writing bad code but I do not consider this case. Typical bugs could be a special data combination that for example is missing in some look-up database. And documentation for your own code is easier and even better than plain tests. So unless you deal with weak programmers I don't see an argument for TDD. Commented Aug 3, 2012 at 9:42