Hacker News Reader

Comment by austenallred | Hacker News Reader

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.

View on HN

> 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.

"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.

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).

TDD will as often as not (and maybe even mostly) surface errors (or gaps) in the specifications rather than errors in the code.

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.

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.

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.)

> 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?

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.

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.

> 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!

> "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.

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.

> 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.

> 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.

> 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...

Reply on news.ycombinator.com