![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
" Be humble about what your unit tests can achieve, unless you have an extrinsic requirements oracle for the unit under test. Unit tests are unl ikely to test more than one trillionth of the functionality of any given method in a reasonable testing cycle. Get over it.
...
If you find your testers splitting up functions to support the testing process, you’re destroying your system architecture and code comprehensi on along with it. Test at a coarser level of granularity
..
I told my client that I could gue ss that many of their tests might be tautological. Maybe all a functio n does is sets X to 5, and I'll bet there's a test of that function to see if the value of X is 5 after it runs.
..
If you cannot tell how a unit te st failure contributes to product risk, you shou ld evaluate whether to throw the test away. There are better techniques to attack quality lapses in the absence of formal corr ectness criteria, such as exploratory testing and Monte Carlo techniques. (Those are great and I view them as being in a category separate from what I am addressing here.) Don’t use unit tests for such validation
..
Note that there are some units fo r which there is a clear answer to the business value question. One such set of tests is regression tests; however, thos e rarely are written at the unit level but rather at the system level. We know what bug will come back if a regression test fails — by construction. Also, some systems have key algor ithms — like ne twork routing algorithms — that are testable against a single API. There is a formal oracle for deriving the tests for such APIs, as I said above. So those unit tests have value.
..
The naïve tester will try to tease data from the tails by keeping a ll the tests around or even by adding more tests; that leads ex actly to the situation my client found himself in, with more co mplexity (or code mass or choose-your-favourite-measure) in the tests than in the code
..
One technique commonly confused with unit testing, and which uses unit test s as a techique, is Test-Driven Development. People believe th at it improves coupling and cohesion metrics but the empiri cal evidence indicates otherwise (one of several papers that debunk this notion with an empirical basis is Janzen and Saledian, “Does Test-Driven Development Really Improve Softwa re Design Quality?” IEEE Software 25 (2), March/April 2008, pp. 77
...
When I look at most unit tests — especially those written with JUnit — they are assertions in disguise.
Turn unit tests into assertio ns.
...
Developers should be integrating continuously and doing system testing continuously rather than focusing on th eir unit tests and postponing integration, even by an hour. So get rid of unit tests that duplicate what system tests al ready do.
...
