4 ms·

I think this is a specialized instance of the general advice to not test code which has not yet been written. If you're writing a test ahead of the code which i

I think this is a specialized instance of the general advice to not test code which has not yet been written. If you're writing a test ahead of the code which it tests, you'd better have every single line of that code already written in your head.

diolpah 15y ago
This is not how TDD is generally practiced, though. The test is written first because it serves as an interface specification. Just as in traditional development, the specification comes before implementation.
- MostAwesomeDude 15y ago
  Why can't there be an interface specification beyond the testing layer? Why can't the API be specified, then the code written, and then the tests written once the initial API is implemented?
gte910h 15y ago
TDD has red:green testing a central principle. You're SUPPOSED to write the test ahead of the code which it tests.
- MostAwesomeDude 15y ago
  One is also supposed to never change the test after it has been etched in stone, especially in BDD, but good luck getting people to follow that rule, especially in this modern age of Agileish development cycles. TDD, if practiced exactly as originally described, ends up being a drain on resources. You care more about the tests than about the code being tested. As a now-classic example, observe a TDD master struggling with Sudoku: http://xprogramming.com/articles/oksudoku/ http://xprogramming.com/articles/oksudoku/
  - gte910h 15y ago
    > to not test code which has not yet been written. You're not doing TDD if you're writing tests afterwords, you're just writing unit tests. I'm not trying to dissuade you from that but just pointing out you're using the wrong term if you're not doing that. I'm not a TDD proponent for most types of work that aren't heavily interfaced based, webservices to iPhone apps, I TDD them, but the actual app internals? Only on certain parts.
  - samstokes 15y ago
    Wait, I've never seen anyone recommend never changing the test - of course you may have to change it, if requirements change and it now tests the wrong thing, or if you deleted the code it was testing, or if there's simply a bug in the test code. BDD encourages higher-level, whole-system tests alongside low-level unit tests, so the conditions for changing a behavioural spec should (hopefully!) happen less often, but I still don't see why you would avoid changing a test if it was wrong or no longer relevant.
pyre 15y ago
Writing tests, even generic ones ahead of time forces you to think about the requirements of what you're writing (edge cases, general case, etc). It doesn't matter if the tests need to be tweaked or even rewritten because the final implementation was different than what you envisioned.
- MostAwesomeDude 15y ago
  How can you know about edge cases without knowing lower-level implementation details? How can you test behavior for a unit without understanding the code which comprises the unit? One of the tenets of TDD is not testing obvious things, and there are bunches of obvious things which can permanently eliminate corners from an implementation. Overtesting is a real danger if one dogmatically forces their tests to specify the limits of the API.
  - ZeroGravitas 15y ago
    http://en.wikipedia.org/wiki/Black-box_testing http://en.wikipedia.org/wiki/Black-box_testing

diolpah 15y ago

This is not how TDD is generally practiced, though. The test is written first because it serves as an interface specification. Just as in traditional development, the specification comes before implementation.

MostAwesomeDude 15y ago
Why can't there be an interface specification beyond the testing layer? Why can't the API be specified, then the code written, and then the tests written once the initial API is implemented?

gte910h 15y ago

TDD has red:green testing a central principle. You're SUPPOSED to write the test ahead of the code which it tests.

MostAwesomeDude 15y ago
One is also supposed to never change the test after it has been etched in stone, especially in BDD, but good luck getting people to follow that rule, especially in this modern age of Agileish development cycles. TDD, if practiced exactly as originally described, ends up being a drain on resources. You care more about the tests than about the code being tested. As a now-classic example, observe a TDD master struggling with Sudoku: http://xprogramming.com/articles/oksudoku/ http://xprogramming.com/articles/oksudoku/
- gte910h 15y ago
  > to not test code which has not yet been written. You're not doing TDD if you're writing tests afterwords, you're just writing unit tests. I'm not trying to dissuade you from that but just pointing out you're using the wrong term if you're not doing that. I'm not a TDD proponent for most types of work that aren't heavily interfaced based, webservices to iPhone apps, I TDD them, but the actual app internals? Only on certain parts.
- samstokes 15y ago
  Wait, I've never seen anyone recommend never changing the test - of course you may have to change it, if requirements change and it now tests the wrong thing, or if you deleted the code it was testing, or if there's simply a bug in the test code. BDD encourages higher-level, whole-system tests alongside low-level unit tests, so the conditions for changing a behavioural spec should (hopefully!) happen less often, but I still don't see why you would avoid changing a test if it was wrong or no longer relevant.

pyre 15y ago

Writing tests, even generic ones ahead of time forces you to think about the requirements of what you're writing (edge cases, general case, etc). It doesn't matter if the tests need to be tweaked or even rewritten because the final implementation was different than what you envisioned.

MostAwesomeDude 15y ago
How can you know about edge cases without knowing lower-level implementation details? How can you test behavior for a unit without understanding the code which comprises the unit? One of the tenets of TDD is not testing obvious things, and there are bunches of obvious things which can permanently eliminate corners from an implementation. Overtesting is a real danger if one dogmatically forces their tests to specify the limits of the API.
- ZeroGravitas 15y ago
  http://en.wikipedia.org/wiki/Black-box_testing http://en.wikipedia.org/wiki/Black-box_testing