4 ms·

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 towar

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.

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.