On Friday, 5 December 2014 at 15:55:23 UTC, Chris wrote:
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.
If the change is voluntary, you don't only need to change the
test, but all callsites. You are lucky that the unit test warned
you about this !
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).
This is where a test culture plays. It is hard to retrofit
testing in bad design (and it is why it is advised to dev test
along side with the code itself).
