> The primary goal is not to write tests which are as isolated as possible, but rather to gain confidence that the code works according to its functional requirements.
Very long article that leads to a trivial conclusion that unit testing is not a substitute to higher level testing, and carries the overhead effort.
It seems to me the author is addressing cases where unit test coverage is blindly used as dev project metric. PMs are often not familiar with code internals, but they need some assurances that project is on-track. Thus trying to collect insights from whatever output provided by automated tools.
Unit tests can have 100% coverage, but still testing the wrong thing. A common misuse is testing to the actual code, instead of testing the expected behavior.
Unit tests is a developer's tool, not PMs metric. On the other hand Acceptance tests should be the common ground, which may be the Integration tests or a whole separate suite altogether tailored to user requirements.
When coding a function, one needs to test preconditions and assumptions prior to following the main logic. Unit tests serve the very same purpose by enforcing assumptions on Unit level at the granularity that makes sense. Noone needs to test trivial getters and setters, but one needs to ensure that objects remain in valid/known states. Thus Unit tests untie developer's hands to recraft the "unit" without fear that the pearls of correctness would get lost.
Paradoxycally, Unit testing is a productivity tool, just as diagraming, or ... sketching prior to coding. Some developers can maintain a perfect mental picture of their code without any need for such tools. Some devs see design and implementations right away. If I were to inherit their codebase, I'd rather see their assumptions validated, so I don't need to do the coverage by eyeballing the code.
Very long article that leads to a trivial conclusion that unit testing is not a substitute to higher level testing, and carries the overhead effort.
It seems to me the author is addressing cases where unit test coverage is blindly used as dev project metric. PMs are often not familiar with code internals, but they need some assurances that project is on-track. Thus trying to collect insights from whatever output provided by automated tools.
Unit tests can have 100% coverage, but still testing the wrong thing. A common misuse is testing to the actual code, instead of testing the expected behavior.
Unit tests is a developer's tool, not PMs metric. On the other hand Acceptance tests should be the common ground, which may be the Integration tests or a whole separate suite altogether tailored to user requirements.
When coding a function, one needs to test preconditions and assumptions prior to following the main logic. Unit tests serve the very same purpose by enforcing assumptions on Unit level at the granularity that makes sense. Noone needs to test trivial getters and setters, but one needs to ensure that objects remain in valid/known states. Thus Unit tests untie developer's hands to recraft the "unit" without fear that the pearls of correctness would get lost.
Paradoxycally, Unit testing is a productivity tool, just as diagraming, or ... sketching prior to coding. Some developers can maintain a perfect mental picture of their code without any need for such tools. Some devs see design and implementations right away. If I were to inherit their codebase, I'd rather see their assumptions validated, so I don't need to do the coverage by eyeballing the code.