Hacker News Reader

Comment by kscaldef | Hacker News Reader

Ah, yes, the "I don't have to write tests because I'm perfect" school of programming.

1) You aren't perfect.

2) Your coworkers aren't perfect.

3) Your "abstractions" are still code that can have errors in it

Also, you are misunderstanding the argument that TDD speeds you up. Yes, at the micro level it may take a bit more time. But, as the system grows, your ability to add or change functionality without breaking things increases when you have tests to verify that it is still correct. (Also, automated testing is much, much faster than manual testing.)

View on HN

But, as the system grows, your ability to add or change functionality without breaking things

I disagree unless all your changes are really shallow. You change the structure of your application in significant ways and you'll break the tests too. So now you have two problems.

The code and the tests go together. You don't just make a pile of code, and a pile of tests, and hope they all go together right.

You have some big tests that are general and test that all the components work together, but for each component you have lots of little tests, and if you are going to change the component you change the tests FIRST. That's TDD.

You deliberately break the tests before you change one line of the actual code.

See, I think the value in tests would be that they are reusable. If you're smart enough to write a test for a situation, then you're smart enough to code for that situation in the first place (and conversely if you miss an edge case in code, you're just as likely to miss an edge case in testing). If you're constantly rewriting your tests -- what's the gain?

Now certainly writing everything twice is actually a great way to catch errors. NASA does that with the shuttle. But I wouldn't argue that its faster.

I prefer to just liberally sprinkle my code with run-time assertions. We have a small defect rate even after pushing out massive structural changes to the application. The bugs that we do have tend to involve an unpredictable set of conditions that no automated test would ever be written to find.

"I disagree unless all your changes are really shallow."

You are correct sir! What the tests do is allow you to refactor (reorganize or clean up code) and verify that you haven't changed functionality. That's the theory.

In practice however you are hardly ever refactoring for its own sake. In most cases you can't really justify paying developers to change code without some benefit that someone (i.e. a customer) will pay YOU for. And as soon as you start changing behaviors, you now have to change code and tests (or write new tests).

Ah, yes, the "I don't have to write tests because I'm perfect" school of programming.

Well, I'm not perfect, but I aspire to write perfect code, that is, code which has no bugs. One way of doing that is writing unit tests - telling the computer what to do, and then telling it how to check what I just told it to do. A better way is making sure I'm using abstractions that match my intentions.

Aside: I see TDD as a little different from regression testing, which seems to make a little more sense.

And an even better way is to do both. You've created a completely false dichotomy.

Good point. I'd argue that either one discourages the other, however. The messier and more complex your architecture, the more valuable tests are. Conversely, the more unit tests you have, the sloppier you can make your architecture.

And I'd argue the opposite. Messy, complex designs are hard to unit test. Writing unit tests encourages clean, well-defined, orthogonal interfaces.

0) no test is perfect

Exactly. Do you write tests for your tests?

In one TDD shop I worked in, test failures were often as not due to bugs in the test code as in the app code.

Reply on news.ycombinator.com