Hacker News Reader

Comment by Arnt | Hacker News Reader

I've heard words much like those many, many times, but always in general or specific to a context where it didn't apply.

For example when I changed some code for which tests didn't exist, so I tested what I changed and wrote some extra tests while I was at it, and it was blocked in code review because my extra tests didn't report failure in any detail. What I did said "x failed" if a test failed, no details. The reviewer said much the same as you did now to justify that additional reporting was absolutely required.

It's a fine sentiment when it actually applies, and I wish it weren't applied quite to often to justify YAGNI and other rubbish.

View on HN

Can you say specifically what you object to in his words above? I'm failing to connect what he said with your complaint.

The advice you received with regards to defect locality sounds reasonable - tests that don't give much in the way of isolation can cost a lot of developer time to hone in on. It's hard to say, not knowing the exact details however.

I also find it hard to reconcile the idea that "tests are an important tool for writing good software" with "justifying YAGNI". How would an "openness for developer testing" justify an attitude of "not writing things you don't need"? Those two concepts sound almost entirely orthogonal.

Unit tests are important to that goal. But that doesn't make every aspect of every unit test important as such.

Specifically, if a test passes right away, then its error reporting isn't important today. It probably comes in useful if the test ever breaks, but will the test ever break? Therefore, spending significant time on the error reporting today is YAGNI, even if minimal version of the test is useful.

My complain is that even if unit tests are useful to a degree, people trot out the reasons for usefulness primarily when those reasons do NOT apply.

I cannot disagree more. If you are bothering to write a test in the first place, do it right. There is nothing worse as a developer than receiving a ticket or a user report saying "It broke; fix it" with no other information.

Not to mention it will literally take you 2 minutes to add the better reporting.

Ok, I see what you're getting at there.

So if it takes you significant time to get proper defect locality, I think you should see if there's a better way to approach the problem. This should be essentially the default for typical/modern unit tests. Perhaps you're writing tests that are more like system level tests?

I'd also say that if you're essentially certain a test will never break, then (other than for documentation purposes) why are you writing it? To paraphrase Kent Beck - we should only test things that could possibly break.

You might be overgeneralizing what "people" say about unit tests - I'm not sure what your specific scenario is, but there are a whole spectrum of opinions on the subject. Perhaps this is just an organizational code-smell of the place you're mentioning.

Dogmatism/cargo culting in general can be annoying however.

>What I did said "x failed" if a test failed, no details.

Yuck. Imagine if you got a bug report that just said "X failed" with no details.

Reply on news.ycombinator.com