3 ms·
This is true if your units under tests are bad abstractions. If you don't know yet what you will build, if your requirements change all the time, good abstracti
by Tainnor 6y ago
This is true if your units under tests are bad abstractions. If you don't know yet what you will build, if your requirements change all the time, good abstractions maybe rarely emerge and then maybe unit tests make less sense.
However, I've worked on a number of applications where there were very well-defined units that were quite stable in terms of their abstraction, and then unit tests are a joy. "I have this tree structure and I need to transform it into another structure" and stuff like that.
It's also worth keeping in mind that "unit testing" doesn't have to mean "class (or method) testing". Sometimes the class is the right level of abstraction but sometimes it can also be a small module of classes working in concert etc.
I agree that tests shouldn't simply reflect implementation, but there are functional requirements that can be specified at a lower level.
- closeparen 6y agoIf I design tests to capture the spirit of the class / module, the line coverage is only 50-60%. In Go each method needs a lot of individual attention to exercise all the error return branches up to a 90%+ coverage standard.
- pydry 6y agoI agree. Good, stable abstractions covering complicated logic are where unit tests shine. Unfortunately I find this scenario is also more the exception than the rule. Big ball of mud apps with few effective tests are the norm and apps which do very little complex logic under the hood (focused instead mainly on hooking together services) are also not at all uncommon.