5 ms·

The problem with TDD is that we flawed humans are writing the tests in the first place. If I suck at writing code there's no reason to believe I wouldn't suck a

The problem with TDD is that we flawed humans are writing the tests in the first place. If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code. I use it on occasion as a good sanity check to make sure I didn't break anything too obvious, but this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place.

_puk 9y ago
"I use it on occasion as a good sanity check to make sure I didn't break anything too obvious" That sounds more like unit tests than TDD. With TDD you should already know that you didn't break anything.. If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input; it is not however going to determine if you did that in the best possible way.
- deleted 9y ago
  [deleted]
- eropple 9y ago
  This is a good and cool post. TDD is less susceptible to "sucky code" for two reasons: 1) It should be a direct port of your specification. If you don't have a specification, you can't do TDD. 2) It should be written by someone who won't be writing the code. Or, at minimum, checked over by someone who won't be writing the code. Writing tests after you've written code strongly encourages you to write implementation tests rather than specification tests. Both are important and useful, but for separate things (if you have to change your specification tests it's probably because you need to bump a minor or major version number for your software).
  - ams6110 9y ago
    TDD will as often as not (and maybe even mostly) surface errors (or gaps) in the specifications rather than errors in the code.
    - eropple 9y ago
      100%. This is perhaps one of its most powerful attributes. Whether I have a spec written on paper or one I've informally defined in my head, I very often find myself enumerating the potential failure cases (determining the domain and range of my code, as it were) and going "hey...wait a minute...what about X?". Writing tests after code is completed, on the other hand, lends itself to reifying an implementation as "correct" and divergence from the implementation as being wrong. No bueno.
  - lgunsch 9y ago
    Regarding your second point, it is not only very difficult, but also not even how TDD was designed to work by its original creators at all. It is specifically not written by other people. TDD, as outlined by the one who created the technique, as well as other big proponents such as Robert Martin, is done in tight 2 or 3 minute loops. As Kent Beck says, if you can't write your test in 5 minutes, you're doing too much.
    - eropple 9y ago
      How "its creators" designed it to work, and how I find it to work in practice, are pretty different. I've found that having two people understand a spec to the level where they can reason about it (and that the best artifact for demonstrating that reasoning is a test suite) is the most straightforward way to build reasonably correct code. (I mean, heck. Theoretically, Agile's "creators" designed it to be useful and helpful to developers. Cue sad trombone sound.)
- falcolas 9y ago
  > If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input Well, if you suck at writing code, what guarantees do you have that the tests (which are also code you write) are even correct?
  - deleted 9y ago
    [deleted]
  - AnimalMuppet 9y ago
    You don't have any such guarantees. But your test would have to be broken in the same way that your real code is broken, not in some different way.
    - falcolas 9y ago
      Well, if the test is accidentally testing the wrong input/output pairs, your code can pass the test perfectly and still be broken. Especially if you follow the "build to the test" mantra.
buttscicles 9y ago
> this idea that TDD is a panacea where no bugs ever survive I don't think I've heard many people claim that. Rather the point I've seen made is that it not only ensures you've got tests, doing them up front encourages developers to write code in a way that is easy to test, which usually happens to be higher quality, more loosely coupled code. When it comes to writing code there are no silver bullets, TDD included.
- auserperson 9y ago
  I've seen many managers think that way.
fmoralesc 9y ago
> The problem win TDD is that we flawed humans are writing the tests in the first place. A general AI could have the same kind of problem, and if we had specialized AIs, we could presumably create the target software directly anyway...
Ace17 9y ago
> If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code. Actually, there is ; providing the difficulty is algorithmic. Take "sort", for example. // test code assertEquals([1,2,3,4,5], sort([4, 1, 2, 3, 5])) // production code int[] mySort(int[] list) { // TODO: implement a sorting algorithm here. } Any programmer could write a fairly good test suite for "sort". However, I highly doubt they could write the implementation. Of course, this is a very simple example. Most of the times, the difficulty lies in finding the proper interface between test and production code. And there, there's no way to compensate for poor software design skills. Actually, forcing bad software designers to test the code they write might even worsen the situation, by rigidifying poorly-designed-wannabe-interfaces. > this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place. This is the software industry ; new techniques are confused with silver bullets!
- strictnein 9y ago
  > "Any programmer could write a fairly good test suite for "sort". However, I highly doubt they could write the implementation." I mean, any developer should be able to write a sort. They might end up with some O(2^n) behemoth, but they should be able to do it.
  - bluGill 9y ago
    Any developer should know the basic algorithms. If you tell one to write sort they should immediately think to look up merge sort is implemented. My algorithm will be O(n ln n), not because I'm great at creating algorithms but because I know I can do better.
dragonwriter 9y ago
> this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place. I've literally never encountered this idea, in person or otherwise, from anyone advocating TDD, only as a an argument TDD opponents like this attack. I'm not sure if it's a rare argument they've latched onto, a common misunderstanding of the purpose of TDD, or an outright strawman, but it's certainly not the main argument (or one of them) I've seen for TDD. TDD: 1. Validates that you have a reasonably clear operational understanding of the intended behavior (but not completeness), forcing more questions out early and preventing some portion of the waste of code aimed at something that isn't the intended functionality that would otherwise occur, and 2. Assures that automated tests (which are often most valuable for regression testing later changes) actually get written, which is a significant issue in practice with test-last processes.
bluGill 9y ago
> this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place. The idea only exists as a straw man for those trying to attack TDD. TDD doesn't ensure there are no bugs. TDD ensures that everything you can think of that can go wrong does not, even as you think of new ways something could go wrong and fix that. I was in one job a few years back without tests. We had a case where someone got a bug which was easy to fix, but they didn't realize their fix broke something else. Then we released and got the bug report which was fixed by reverting back to the original bug - we went through 3 rounds (over 6 years - a different contractor on the bug each time so who didn't realize what was going on) before someone realized what was happening and fixed both bugs.

_puk 9y ago

"I use it on occasion as a good sanity check to make sure I didn't break anything too obvious" That sounds more like unit tests than TDD. With TDD you should already know that you didn't break anything.. If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input; it is not however going to determine if you did that in the best possible way.

deleted 9y ago
[deleted]
eropple 9y ago
This is a good and cool post. TDD is less susceptible to "sucky code" for two reasons: 1) It should be a direct port of your specification. If you don't have a specification, you can't do TDD. 2) It should be written by someone who won't be writing the code. Or, at minimum, checked over by someone who won't be writing the code. Writing tests after you've written code strongly encourages you to write implementation tests rather than specification tests. Both are important and useful, but for separate things (if you have to change your specification tests it's probably because you need to bump a minor or major version number for your software).
- ams6110 9y ago
  TDD will as often as not (and maybe even mostly) surface errors (or gaps) in the specifications rather than errors in the code.
  - eropple 9y ago
    100%. This is perhaps one of its most powerful attributes. Whether I have a spec written on paper or one I've informally defined in my head, I very often find myself enumerating the potential failure cases (determining the domain and range of my code, as it were) and going "hey...wait a minute...what about X?". Writing tests after code is completed, on the other hand, lends itself to reifying an implementation as "correct" and divergence from the implementation as being wrong. No bueno.
- lgunsch 9y ago
  Regarding your second point, it is not only very difficult, but also not even how TDD was designed to work by its original creators at all. It is specifically not written by other people. TDD, as outlined by the one who created the technique, as well as other big proponents such as Robert Martin, is done in tight 2 or 3 minute loops. As Kent Beck says, if you can't write your test in 5 minutes, you're doing too much.
  - eropple 9y ago
    How "its creators" designed it to work, and how I find it to work in practice, are pretty different. I've found that having two people understand a spec to the level where they can reason about it (and that the best artifact for demonstrating that reasoning is a test suite) is the most straightforward way to build reasonably correct code. (I mean, heck. Theoretically, Agile's "creators" designed it to be useful and helpful to developers. Cue sad trombone sound.)
falcolas 9y ago
> If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input Well, if you suck at writing code, what guarantees do you have that the tests (which are also code you write) are even correct?
- deleted 9y ago
  [deleted]
- AnimalMuppet 9y ago
  You don't have any such guarantees. But your test would have to be broken in the same way that your real code is broken, not in some different way.
  - falcolas 9y ago
    Well, if the test is accidentally testing the wrong input/output pairs, your code can pass the test perfectly and still be broken. Especially if you follow the "build to the test" mantra.

buttscicles 9y ago

> this idea that TDD is a panacea where no bugs ever survive I don't think I've heard many people claim that. Rather the point I've seen made is that it not only ensures you've got tests, doing them up front encourages developers to write code in a way that is easy to test, which usually happens to be higher quality, more loosely coupled code. When it comes to writing code there are no silver bullets, TDD included.

auserperson 9y ago
I've seen many managers think that way.

fmoralesc 9y ago

> The problem win TDD is that we flawed humans are writing the tests in the first place. A general AI could have the same kind of problem, and if we had specialized AIs, we could presumably create the target software directly anyway...

Ace17 9y ago

> If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code. Actually, there is ; providing the difficulty is algorithmic. Take "sort", for example. // test code assertEquals([1,2,3,4,5], sort([4, 1, 2, 3, 5])) // production code int[] mySort(int[] list) { // TODO: implement a sorting algorithm here. } Any programmer could write a fairly good test suite for "sort". However, I highly doubt they could write the implementation. Of course, this is a very simple example. Most of the times, the difficulty lies in finding the proper interface between test and production code. And there, there's no way to compensate for poor software design skills. Actually, forcing bad software designers to test the code they write might even worsen the situation, by rigidifying poorly-designed-wannabe-interfaces. > this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place. This is the software industry ; new techniques are confused with silver bullets!

strictnein 9y ago
> "Any programmer could write a fairly good test suite for "sort". However, I highly doubt they could write the implementation." I mean, any developer should be able to write a sort. They might end up with some O(2^n) behemoth, but they should be able to do it.
- bluGill 9y ago
  Any developer should know the basic algorithms. If you tell one to write sort they should immediately think to look up merge sort is implemented. My algorithm will be O(n ln n), not because I'm great at creating algorithms but because I know I can do better.

dragonwriter 9y ago

> this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place. I've literally never encountered this idea, in person or otherwise, from anyone advocating TDD, only as a an argument TDD opponents like this attack. I'm not sure if it's a rare argument they've latched onto, a common misunderstanding of the purpose of TDD, or an outright strawman, but it's certainly not the main argument (or one of them) I've seen for TDD. TDD: 1. Validates that you have a reasonably clear operational understanding of the intended behavior (but not completeness), forcing more questions out early and preventing some portion of the waste of code aimed at something that isn't the intended functionality that would otherwise occur, and 2. Assures that automated tests (which are often most valuable for regression testing later changes) actually get written, which is a significant issue in practice with test-last processes.

bluGill 9y ago

> this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place. The idea only exists as a straw man for those trying to attack TDD. TDD doesn't ensure there are no bugs. TDD ensures that everything you can think of that can go wrong does not, even as you think of new ways something could go wrong and fix that. I was in one job a few years back without tests. We had a case where someone got a bug which was easy to fix, but they didn't realize their fix broke something else. Then we released and got the bug report which was fixed by reverting back to the original bug - we went through 3 rounds (over 6 years - a different contractor on the bug each time so who didn't realize what was going on) before someone realized what was happening and fixed both bugs.