Hacker News Reader

Comment by jhancock | Hacker News Reader

I'm not completely against TDD. However, one thing I've found is bugs are caused by things you didn't think to write a test for (or write your code to handle sans tests). The mundane stuff I see in the vast majority of unit tests are things an experienced programmer almost never screws up. So how do you write a test for a case you couldn't foresee?

My biggest argument in favor of writing tests is to ensure my code doesn't break relative to other people's code. There are many times I've encountered an update to a ruby gem with no major or minor version change that has broken a, usually implied, contract with my code. I say implied, because duck typers, at least what I've seen in the ruby world, tend to be slack about formalizing interfaces. I write tests to protect against that sort of thing.

View on HN

So how do you write a test for a case you couldn't foresee?

You don't, but once you discover it, you write a regression test to make sure it doesn't come back.

However, IANATDD, I am not a test-driven developer - I don't see any reason to be dogmatic, but I do think unit tests can be extremely valuable. So this answer might not be TDD-approved.

"So how do you write a test for a case you couldn't foresee?"

"You don't, but once you discover it, you write a regression test to make sure it doesn't come back."

Sure, that's SOP in any good dev. house that does testing. But you've failed to address a key weakness in TDD. The real question is how do you discover these sorts of defects given that a single developer writing in a TDD style is unlikely to do so? TDD is clearly not a cure all, and this is a major weakness of it. Other development techniques, many of which can complement TDD, such as formal code reviews and beta testing can do a better job of getting you to higher product quality than TDD alone.

"TDD is clearly not a cure all"

Who said it was?

Exactly!! There is no such thing as a cure all. Anybody angry over a technique that does not solve all problems is clearly suffering from the Silver Bullet Syndrome.

What? Why does something have to be perfect for somebody to get angry over it?

Not exactly sure what you are asking. I mainly meant any tool you use will not solve all of your problems. Pretty basic common sense, IMO.

> So how do you write a test for a case you couldn't foresee?

TDD is a design technique, not a testing technique.

For me, I don't always know what the edge cases could be until I write them down. Writing tests allows me to get a clearer picture of what kind of coverage I have.

Another nice thing is you can read what the edge cases are going to be, rather than having to remember them all of the time.

TDD does not claim to fix all of your bugs. You often do not need to theoretically prove your software is correct, so you don't need to have you unit tests test all possible contexts (e.g. handling disk failure vs. any other error when rendering a web page). That is what abstraction is for.

TDD does force you to think about the interface of your abstraction, however. If it is painful to write (or maintain) the test, then that is a good indication that the abstraction is wrong or not being properly tested. Don't be afraid of deleting tests when they are not useful.

I often find that these unanticipated bugs are often due to incorrect abstractions. To fix it, create the correct abstraction and test it.

It is also simply faster to develop in larger projects than creating the state that would test your unit. For example, you could make a change, manually refresh the page, and debug or write the test and make it pass. You also get the benefit of regression testing.

Note that the narrower your unit, the less likely it will be useful for regression purposes.

I often find that when beginning a project, my units are smaller. As abstractions are built, the nonessential tests are deleted and future tests are built upon abstractions that I care about.

Reply on news.ycombinator.com