4 ms·

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 t

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.

Arnt 10y ago
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.
- st3v3r 10y ago
  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.
- switchbak 10y ago
  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.

Arnt 10y ago

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.

st3v3r 10y ago
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.
switchbak 10y ago
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.