5 ms·

>You are writing code to test something that doesn't even exist yet. To piggyback on this... sure, the code doesn't exist yet, but the project specs do. And un

>You are writing code to test something that doesn't even exist yet. To piggyback on this... sure, the code doesn't exist yet, but the project specs do. And unit tests can help by making the required specification explicit.

snowwolf 11y ago
Anecdotal, but 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. Regarding the rest of the article it is pure trolling with nothing really useful to add to the debate.
- DougWebb 11y ago
  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."
eutectic 11y ago
In any other field, specifying a function by its value at a handful of points would be a bad joke. If you don't know what you want your code to do then tests will just make it harder to experiment, and if you do know then there's no harm in writing them after the fact.
- brlewis 11y ago
  When theseatoms says the specs already exist and the tests help, then you talk as if the test was the spec, it sounds like you're replying before you read.
- dllthomas 11y ago
  Bench vices pin down a board at a handful of points. Other things about the environment (shape of board, material properties of wood) help me make sure it generalizes in the ways I care about.
- dragonwriter 11y ago
  > In any other field, specifying a function by its value at a handful of points would be a bad joke. There is a difference between making the spec explicit (which is providing concrete examples of the spec's meaning) and replacing the spec. You seem to be talking about tests doing the latter, while the grandparent comment talked about the former. > If you don't know what you want your code to do then tests will just make it harder to experiment, and if you do know then there's no harm in writing them after the fact. If different people are responsible for the unit under design vs. the parts of the software that will consume that unit, then the concrete examples provided by test cases can help confirm that there is a common understanding of the spec; as such, tests serve to validate the spec. You want to do that before you code the implementation. And once you've done that, the tests are also available to validate the implementation.
mannykannot 11y ago
I agree, but the corollary of that is that if the project specs exist (and they do, at least conceptually), then it is they that are ultimately driving development. This is outside of the scope of TDD, and so TDD is not a complete methodology, a fact that often seems to be forgotten or overlooked.
- dllthomas 11y ago
  I've been wanting (and, off and on, building) a system for tying documentation to supporting tests. On the one hand, it should serve as citations, making sure I don't make claims I can't hold up. On the other, it should help avoid the docs drifting out of sync with the code without undue cognitive overhead - telling me what I need to consider changing when the code changes. One option would be to start with a spec and gradually add citations, doing TDD along the way for a sort of Documentation Driven Development, although I've no particular confidence that's actually a sweet spot. doctest is a move in this direction, but only really makes sense for code you wish to surface as examples. Cucumber is also obviously related, but - so far as I understand - isn't really suitable for producing arbitrary documentation. Types are (amongst other things) another form of machine checked documentation, but the audience (and, usually, expressiveness) is naturally limited.

snowwolf 11y ago

Anecdotal, but 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. Regarding the rest of the article it is pure trolling with nothing really useful to add to the debate.

DougWebb 11y ago
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."

eutectic 11y ago

In any other field, specifying a function by its value at a handful of points would be a bad joke. If you don't know what you want your code to do then tests will just make it harder to experiment, and if you do know then there's no harm in writing them after the fact.

brlewis 11y ago
When theseatoms says the specs already exist and the tests help, then you talk as if the test was the spec, it sounds like you're replying before you read.
dllthomas 11y ago
Bench vices pin down a board at a handful of points. Other things about the environment (shape of board, material properties of wood) help me make sure it generalizes in the ways I care about.
dragonwriter 11y ago
> In any other field, specifying a function by its value at a handful of points would be a bad joke. There is a difference between making the spec explicit (which is providing concrete examples of the spec's meaning) and replacing the spec. You seem to be talking about tests doing the latter, while the grandparent comment talked about the former. > If you don't know what you want your code to do then tests will just make it harder to experiment, and if you do know then there's no harm in writing them after the fact. If different people are responsible for the unit under design vs. the parts of the software that will consume that unit, then the concrete examples provided by test cases can help confirm that there is a common understanding of the spec; as such, tests serve to validate the spec. You want to do that before you code the implementation. And once you've done that, the tests are also available to validate the implementation.

mannykannot 11y ago

I agree, but the corollary of that is that if the project specs exist (and they do, at least conceptually), then it is they that are ultimately driving development. This is outside of the scope of TDD, and so TDD is not a complete methodology, a fact that often seems to be forgotten or overlooked.

dllthomas 11y ago
I've been wanting (and, off and on, building) a system for tying documentation to supporting tests. On the one hand, it should serve as citations, making sure I don't make claims I can't hold up. On the other, it should help avoid the docs drifting out of sync with the code without undue cognitive overhead - telling me what I need to consider changing when the code changes. One option would be to start with a spec and gradually add citations, doing TDD along the way for a sort of Documentation Driven Development, although I've no particular confidence that's actually a sweet spot. doctest is a move in this direction, but only really makes sense for code you wish to surface as examples. Cucumber is also obviously related, but - so far as I understand - isn't really suitable for producing arbitrary documentation. Types are (amongst other things) another form of machine checked documentation, but the audience (and, usually, expressiveness) is naturally limited.