Unit Tests Considered Harmful
shaiyallin.com
Unit Tests Considered Harmful
1–10 of 76 posts
Re: Unit Tests Considered Harmful
#2The target audience for unit tests is not the client, it is the developer. Unit tests allow you to change code with more confidence. 100% code coverage is not a useful aim, you should aim for 100% confidence in your code. Unit tests can also function as example code, that can't get out of date, since then the tests will fail.
Testing for quality assurance is a different thing, usually called acceptance testing and sometimes including regression testing. One easy way to make clients angry is by re-introducing bugs that were fixed in earlier releases.
Re: Unit Tests Considered Harmful
#3The target audience for unit tests is not the client, it is the developer. Unit tests allow you to change code with more confidence. 100% code coverage is not a useful aim, you should aim for 100% confidence in your code. Unit tests can also function as example code, that can't get out of date, since then the tests will fail. Testing for quality assurance is a different thing, usually called acceptance testing and so…
I agree. The post completely misses the point of unit testing in the first place by drawing a relationship to the features being implemented.
Re: Unit Tests Considered Harmful
#4If your not Dijkstra then using title like that negatively affects people's perception of your post.
Re: Unit Tests Considered Harmful
#5The target audience for unit tests is not the client, it is the developer. Unit tests allow you to change code with more confidence. 100% code coverage is not a useful aim, you should aim for 100% confidence in your code. Unit tests can also function as example code, that can't get out of date, since then the tests will fail. Testing for quality assurance is a different thing, usually called acceptance testing and so…
How do you measure 100% confidence? Pretty sure I have never reached 100% confidence, but I haven't had a metric to track it so I have no data to prove it.
The only possible way to reach near 100% is I think by not writing any code, and by not building anything.
I do think 100% code coverage goal doesn't mean much, since you can potentially achieve it using 0 assertions. Or you make 1 assertion per test, leaving 95%+ expected results unasserted. Assertions could also be wrong.
Re: Unit Tests Considered Harmful
#6If your not Dijkstra then using title like that negatively affects people's perception of your post.
“Considered Harmful” considered harmful? :)
Re: Unit Tests Considered Harmful
#7[deleted]
Re: Unit Tests Considered Harmful
#8The target audience for unit tests is not the client, it is the developer. Unit tests allow you to change code with more confidence. 100% code coverage is not a useful aim, you should aim for 100% confidence in your code. Unit tests can also function as example code, that can't get out of date, since then the tests will fail. Testing for quality assurance is a different thing, usually called acceptance testing and so…
How do you measure 100% confidence? Pretty sure I have never reached 100% confidence, but I haven't had a metric to track it so I have no data to prove it. The only possible way to reach near 100% is I think by not writing any code, and by not building anything. I do think 100% code coverage goal doesn't mean much, since you can potentially achieve it using 0 assertions. Or you make 1 assertion per test, leaving 95%+…
You measure how many of your deployments ship broken code. I've worked in contexts where test coverage was sufficient enough to be confident that when deploying there wouldn't be any issues apart from really novel unexpected stuff you wouldn't have tested anyway.
I've also worked in contexts wher I didn't have that confidence.
I would say you know when you're in that environment and directly measuring doesn't really help as it's more a matter of culture than technical metrics.
Re: Unit Tests Considered Harmful
#9It keeps coming back to the same stupid erosion of paradigms.
Once upon a time, some developers that were smarter than others started testing their code. They described ways to test smaller parts of large software systems separately before being integrated together.
For instance "parameter testing" (to validate component subprograms against their specification) and "assembly testing" (for parts put together)[^1]
As always happens, a formal definition soon followed and the industry settled on names like "unit tests", "component tests" and "integration tests".[^2]
Of course, as soon as things are describes somewhere, this means there is documentation for developer to ignore. Or misinterpret.
Next thing you know, "Unit-Testing" is (ab)used, and people start complaining it doesn't work.
So some developers that were smarter than others say "You are doing it wrong!" and describe a better way of doing things... For instance, writing the test _before_ you write the code, so the scale/scope of a "unit" is defined beforehand. There is much rejoicing, and TDD is the new magic bullet.
So now there is more documentation for developer to ignore. So some developers that were smarter than others say "You are doing it wrong!" and define BDD, which is basically just TDD "done right", as the term TDD has become polluted. [^4]
So now there is more documentation for developer to ignore. So some developers that were smarter than others say "You are doing it wrong!" and define DDD, which is basically just BDD "done right", as the term BDD has become polluted.
And so the merry dance continues.
Rather than understanding which practice helps improve quality in which (coding) problem domain, developers stomp around with their preferred hammer, looking for nails, complaining about everybody else's hammer.
I'd say, rather than using one or the other, based on developer desired, focus on things from the user perspective... Take a look at the Test Automation Pyramid and start writing the right tests in the right domains depending on business/domain value.
[^1]: H.D. Benington, 1956 [^2]: James J. Donegan; Calvin Packard; Paul Pashby, 1964 and Norman A. Zimmerman, 1969 [^3]: Lee Copeland, 2001 [^4]: Dan North 2006
Re: Unit Tests Considered Harmful
#10The clue is in the name. Unit Tests test units of code (how ever you want to define it. Integration Tests test how units of code work together.
Perspective is also useful. What looks like an integration test to a low level developer, could be a unit test higher up the stack.