On Friday, 5 December 2014 at 15:44:35 UTC, Wyatt wrote:
On Friday, 5 December 2014 at 14:53:43 UTC, Chris wrote:
As I said, I'm not against unit tests and I use them where
they make sense (difficult output, not breaking existing
tested code). But I often don't bother with them when they
tell me what I already know.
assert(addNumbers(1,1) == 2);
I've found myself in the position when unit tests give me a
false sense of security.
Sure, you need to test the obvious things,
Everywhere? For each function? It may be desirable but hard to
maintain. Also, unit tests break when you change the behavior of
a function, then you have to redesign the unit test for this
particular function. I prefer unit tests for bigger chunks.
but I find the real gains come from being able to verify the
behaviour of edge cases and pathological input; and,
critically, ensuring that that behaviour doesn't change as you
refactor. (My day job involves writing and maintaining legacy
network libraries and parsers in pure C. D's clean and easy
unit tests would be a godsend for me.)
-Wyatt
True, true. Unfortunately, the edge cases are usually spotted
when using the software, not in unit tests. They can be included
later, but new pathological input keeps coming up (especially if
you write for third party software).
Now don't get me wrong, I wouldn't want to miss unit tests in D,
but I use them more carefully now, not everywhere.
