3 ms·

I've always found that if you can't write the test first it's a good indication that you probably don't yet have a good enough understanding of the problem you

I've always found that if you can't write the test first it's a good indication that you probably don't yet have a good enough understanding of the problem you are trying to solve. The author's point, in the painting comparison and when mentioning other fields, is that you never have a good enough understanding of the problem you are trying to solve when you're just starting to work on it. Developing the code is an iterative process that refines your understanding of the problem and the correct solution, and only once you've done that do you know enough to write appropriate tests. There are exceptions to this, but they tend to be less common or trivial. If you're implementing a known algorithm, such as an implementation of a mathematical function, you know enough to write the test cases first. You can do it for very generic libraries too, like a library of sorting methods. But in practice most code is not so easy to spec completely before you start to implement it.

bryanlarsen 11y ago
> But in practice most code is not so easy to spec completely before you start to implement it. No TDD advocates say you should spec completely before you start to implement. Most say you should write a single, very simple test. It's not much more than the function signature, and almost everybody in almost every language writes the function signature before writing the code.
snowwolf 11y ago
And my point is the opposite Developing the tests is an iterative process that refines your understanding of the problem and the correct solution, and only once you've done that do you know enough to write appropriate code.
- dllthomas 11y ago
  On a related note, when it comes to types I find very odd the persistent notion that a statically typed language means it's vital that you get the types right at the outset. Quite the contrary, as we build anything, we necessarily pick some way of organizing our code and our data. When we inevitably discover that we were horribly wrong, it is tremendously valuable to be told more about what needs to change in concert as we reorganize.
- DougWebb 11y ago
  Maybe it's a matter of personal style. Some people are better if they focus on "how do I write the code that's intended to solve my problem", and some people are better if they focus on "how do I write tests that can determine that my problem is solved, and that the solution is correct."

bryanlarsen 11y ago

> But in practice most code is not so easy to spec completely before you start to implement it. No TDD advocates say you should spec completely before you start to implement. Most say you should write a single, very simple test. It's not much more than the function signature, and almost everybody in almost every language writes the function signature before writing the code.

snowwolf 11y ago

And my point is the opposite Developing the tests is an iterative process that refines your understanding of the problem and the correct solution, and only once you've done that do you know enough to write appropriate code.

dllthomas 11y ago
On a related note, when it comes to types I find very odd the persistent notion that a statically typed language means it's vital that you get the types right at the outset. Quite the contrary, as we build anything, we necessarily pick some way of organizing our code and our data. When we inevitably discover that we were horribly wrong, it is tremendously valuable to be told more about what needs to change in concert as we reorganize.
DougWebb 11y ago
Maybe it's a matter of personal style. Some people are better if they focus on "how do I write the code that's intended to solve my problem", and some people are better if they focus on "how do I write tests that can determine that my problem is solved, and that the solution is correct."