4 ms·

Because I find that I do not fully understand a problem and it’s potential solutions until I am working through it in reality.

lgunsch 8y ago
When Kent Beck (credited with helping create TDD) talks about TDD in his book, that is the primary reason for following TDD. He mentions, that if a developer already knows the solution, just do it. TDD is not helping at that point.
elemeno 8y ago
I used to have that view of the world as well, that a lot of the programming I was doing was simultaneously exploring the problem space as well as working towards a solution and thus writing tests (let alone full blown TDD) wouldn't work. I think that what changed my mind, other than the dubious joy of maintaining my own code a couple of years down the line, was the realisation that while I don't know the solution to the problem yet I do know what each function I'm writing is supposed to do and thats what I should be testing. As a side effect it also meant that the functions I was writing became smaller (easier to test) and it became easier to see what the end solution might look like because I could understand the intermediary steps more easily. Or to put it another way, I might not know how to write the compiler, say, but I do know that I'll need to start off by reading a line of input and I can test that I'm doing that properly, etc.
- voodootrucker 8y ago
  Good example: writing a compiler. I started (but never finished) writing a WASM interpreter in JavaScript. (https://github.com/bgard6977/wasm-int https://github.com/bgard6977/wasm-int) My test suite had simple programs in C, and used emcc to compile and run them, then compare the results from a known-good implementation to the one I was writing. As I went, I would add one new instruction to the program at a time. That's a perfect example of outside-in testing, and evolving the requirements, tests, and code simultaneously.
  - kazinator 8y ago
    The test case programs/expressions input into a compiler are external regression test cases. By itself, that is not TDD. External compiler tests may seem TDD-like because they exist first, and make the compiler fail until the required features are working. TDD is about bogging down the code with internal tests that treat every aspect of the code as a committed feature. You cannot do a single thing that doesn't first fail some newly added test, which then goes green.
    - crdoconnor 8y ago
      I call this "unit test driven development". I find it pretty horrible unless the code is largely algorithmic. ATDD works though.
- unimpressive 8y ago
  >As a side effect it also meant that the functions I was writing became smaller (easier to test) and it became easier to see what the end solution might look like because I could understand the intermediary steps more easily. I definitely use "it's hard to test this code" as a smell indicating refactoring is in order. I've never tried TDD, but I suspect most of the value is that it forces people into practicing separation of concerns and other basic anti-ball-of-mud practices.
  - jacques_chester 8y ago
    This is true, but you still go through a painful process of learning what that actually means. My early sins included happily relying on field injection in Spring (don't), happily blasting stuff into Ruby objects (don't), mocking my software's world into an unrecognisable comic book universe of gravity-defying nonsense (don't) and so on. A common criticism of TDD is that poor tests make things harder to change, not easier, and I believe it, because I have absolutely done that.
mpweiher 8y ago
One thing I have found helpful in this sort of situation is to start by writing the exploratory code as a self-contained test. So a test that has no production code it is testing. Preferably in a language with really fast turnaround, a "scripting" language. After a while, I have a self-contained test that does something, and does it reliably. I can then refactor the test by extracting the production code.
- lancerkind 8y ago
  I do this too in cases where I’ve got an “extreme” amount of learning to do. (Learning a new language, a library, or something I’m trying to make work just simply won’t do I break it down into a tiny test). This isn’t my usual TDD workflow but I use it when my understanding of the mangauge or language feature are blocking me.
karmakaze 8y ago
The best way to explore solution space I've found is to make the simplest thing that works end to end then add addional cases. The reason that TDD doesn't work well is that it tends to be done bottom up which often has you building things you don't need, use, or worse use but with a poor fit. So skip TDD if you know exactly what you're doing or have little clue. Use it if you want dopamine hits to motivate continuous progress on average complexity tasks. If it comes out wrong, commit a checkpoint locally, but attempt a refractor now rather than repeatedly paying the debt.
- karmakaze 8y ago
  Having just written this, I can recall a number of times I've pushed the debt rather than follow my own advice. It's due to having written tests that must also be refactored (i. e. debt) and pairing where I don't apply as high a standard to keep moving forward.

lgunsch 8y ago

When Kent Beck (credited with helping create TDD) talks about TDD in his book, that is the primary reason for following TDD. He mentions, that if a developer already knows the solution, just do it. TDD is not helping at that point.

elemeno 8y ago

I used to have that view of the world as well, that a lot of the programming I was doing was simultaneously exploring the problem space as well as working towards a solution and thus writing tests (let alone full blown TDD) wouldn't work. I think that what changed my mind, other than the dubious joy of maintaining my own code a couple of years down the line, was the realisation that while I don't know the solution to the problem yet I do know what each function I'm writing is supposed to do and thats what I should be testing. As a side effect it also meant that the functions I was writing became smaller (easier to test) and it became easier to see what the end solution might look like because I could understand the intermediary steps more easily. Or to put it another way, I might not know how to write the compiler, say, but I do know that I'll need to start off by reading a line of input and I can test that I'm doing that properly, etc.

voodootrucker 8y ago
Good example: writing a compiler. I started (but never finished) writing a WASM interpreter in JavaScript. (https://github.com/bgard6977/wasm-int https://github.com/bgard6977/wasm-int) My test suite had simple programs in C, and used emcc to compile and run them, then compare the results from a known-good implementation to the one I was writing. As I went, I would add one new instruction to the program at a time. That's a perfect example of outside-in testing, and evolving the requirements, tests, and code simultaneously.
- kazinator 8y ago
  The test case programs/expressions input into a compiler are external regression test cases. By itself, that is not TDD. External compiler tests may seem TDD-like because they exist first, and make the compiler fail until the required features are working. TDD is about bogging down the code with internal tests that treat every aspect of the code as a committed feature. You cannot do a single thing that doesn't first fail some newly added test, which then goes green.
  - crdoconnor 8y ago
    I call this "unit test driven development". I find it pretty horrible unless the code is largely algorithmic. ATDD works though.
unimpressive 8y ago
>As a side effect it also meant that the functions I was writing became smaller (easier to test) and it became easier to see what the end solution might look like because I could understand the intermediary steps more easily. I definitely use "it's hard to test this code" as a smell indicating refactoring is in order. I've never tried TDD, but I suspect most of the value is that it forces people into practicing separation of concerns and other basic anti-ball-of-mud practices.
- jacques_chester 8y ago
  This is true, but you still go through a painful process of learning what that actually means. My early sins included happily relying on field injection in Spring (don't), happily blasting stuff into Ruby objects (don't), mocking my software's world into an unrecognisable comic book universe of gravity-defying nonsense (don't) and so on. A common criticism of TDD is that poor tests make things harder to change, not easier, and I believe it, because I have absolutely done that.

mpweiher 8y ago

One thing I have found helpful in this sort of situation is to start by writing the exploratory code as a self-contained test. So a test that has no production code it is testing. Preferably in a language with really fast turnaround, a "scripting" language. After a while, I have a self-contained test that does something, and does it reliably. I can then refactor the test by extracting the production code.

lancerkind 8y ago
I do this too in cases where I’ve got an “extreme” amount of learning to do. (Learning a new language, a library, or something I’m trying to make work just simply won’t do I break it down into a tiny test). This isn’t my usual TDD workflow but I use it when my understanding of the mangauge or language feature are blocking me.

karmakaze 8y ago

The best way to explore solution space I've found is to make the simplest thing that works end to end then add addional cases. The reason that TDD doesn't work well is that it tends to be done bottom up which often has you building things you don't need, use, or worse use but with a poor fit. So skip TDD if you know exactly what you're doing or have little clue. Use it if you want dopamine hits to motivate continuous progress on average complexity tasks. If it comes out wrong, commit a checkpoint locally, but attempt a refractor now rather than repeatedly paying the debt.

karmakaze 8y ago
Having just written this, I can recall a number of times I've pushed the debt rather than follow my own advice. It's due to having written tests that must also be refactored (i. e. debt) and pairing where I don't apply as high a standard to keep moving forward.