Hacker News Reader

But the point was that to know how the function will be consumed before you write it implies you fully specified it ahead of time without the benefit of knowing how--or frankly even if--it will work, which (to me) is backwards.

View on HN

Yes, the point of TDD is to force you to think about what your requirements are—and how you will prove that they have been met—from the users' (and thus the tests') point of view before writing the code.

If you want to take a more exploratory approach and make up the requirements as you go along, fine, but that won't look anything like TDD.

This is where TDD folds in on itself. It's nominally about iteration, but requires that you know how the inputs and outputs will look up front before iterating.

TDD is about iterating on the implementation. If you don't know what your inputs and outputs will look like then you're still in the specification phase and not ready to write code.

You can use TDD as part of an iterative specification process as well, but then you need to apply it for each iteration: determine the new specifications, write new tests based on those specifications, and update the code until the tests pass. Then revise your specifications based on feedback and repeat the process.

Reply on news.ycombinator.com