Hacker News Reader

Comment by jmnicolas | Hacker News Reader

TL;DR

Can anyone that read it provide a summary so that I know if it's worth spending time reading it ?

• Keep regression tests around for up to a year — but most of those will be system-level tests rather than unit tests.
• Keep unit tests that test key algorithms for which there is a broad, formal, independent oracle of correctness, and for which there is ascribable business value.
• Except for the preceding case, if X has business value and you can text X with either a system test or a unit test, use a system test — context is everything.
• Design a test with more care than you design the code.
• Turn most unit tests into assertions.
• Throw away tests that haven’t failed in a year.
• Testing can’t replace good development: a high test failure rate suggests you should shorten development intervals, perhaps radically, and make sure your architecture and design regimens have teeth
• If you find that individual functions being tested are trivial, double-check the way you incentivize developers’ performance. Rewarding coverage or other meaningless metrics can lead to rapid architecture decay.

• Be humble about what tests can achieve. Tests don’t improve quality: developers do

Thanks.

Beautiful.

   >> Throw away tests that haven’t failed in a year.

That's absolutely f*ing crazy. Throwing those tests away makes it impossible for me to know that any changes I make to the implementation are OK.

Why? Don't you use assertions?

No amount of assertions in production code can replace assertions of unit-tests; assuming the unittests are designed to try all known common & edge cases.

Also, assertions only flag code that gets executed when you test it. Unless you can be sure that you have tested every possible execution possibility before shipping, you cannot know if after shipping your code will execute something that you missed during testing. This happens a lot.

Additionally, the unit tests allow me to safely maintain the code from the comfort of my own desk. If I relied only on assertions then I would literally have to send changes to all possible users and ask each of them to please test and tell me if they got any assertions. And do this for me three times a week for the next two years.

Who said only?

It was a long thread but it was worth it. It was very interesting and thought provoking to read so many peoples biases, and insights. I am ready to start implementing tests, and I think that as was stated above, tautological unit tests has no value, unless something inside it may be suspectible to change. When you write a unit test, then you add cohesiveness, so you have to update the unit test when your interface change. In other words. You don't write any regression test before your interface is stable. -On the other hand, you may use that same test as a test driven development test up to that point, and let the test be the manifesto of the specification. For simpler cases, it is often best to use assertions, that you can annhilate when you ship anyway. Apple says that Unit tests are for the model more than the view, but may be used in the controller, so those places I am inclined to use NSAssert. I don't have to throw away unit tests that takes a long time to run in Xcode either, as I can just disable them.

I must also say that I am reluctant to write large tests, and "mock objects" to provider large environments for the code to run in, as that may introduce new bugs and more work.

I guess (hope) the correct stratagems for when to implement tests, and when not comes with experience!

Summary: Unit testing is hard, so it's not worth the effort.

Unit testing is investing in product functional confidence. Don't do it if you don't care about it. Or... do it where you need it most. Consequences are going to be faced thou. It's also educational

I think it is more like use the right tool for job.

Reply on news.ycombinator.com