adam bien's blog

It starts with choosing a framework which especially supports unit testing (NanoContainer, PicoContainer,Spring, Guice, EJB 3 etc.). No one can argue against that. A framework always introduces additional complexity and dependency on the infrastructure, but the increase of test coverage is good for the quality on the other hand and outweights the bloat in general.

After the introduction of such a framework, developers tend to foget about the actual reason of its introduction - the testability. Although every single layer could be easily replaced, mocked and unit tested, it actually happens only rarely. In fact the majority of projects do not use the testing capabilities of the particular framework at all. Not only the test coverage is poor, but especially the quality as well:

1. Only service / transaction boundaries are tested. The classes behind the facades are not. It is actually functional testing, not unit testing. The actual benefits of the "test first" frameworks are not leveraged.
   
2. In continuus integration environments the majority of the tests is even commented out. With this approach sun will always shine in hudson land :-).
3. Only trivial, CRUD-like use cases are tested at all - the hard stuff not. It is mostly driven by the QAs.
   
4. Mocks are only used for trivial cases.
5. Assert statements are only used rarely - sometimes only a subset like Assert.true. System.out.println still rules.
   

I recognized the discrepance between articles, conferences and the reality several years ago. At the conferences the gurus told you how to practice "test first", in reality I was happy about enforcing usable tests at functional level.

At the beginning I thought that it is only my unlucky experience, but I began to ask during conferences, workshops and trainings about the mismatch. I saw only few projects with good test coverage and pragmatic tests so far. These were actually not business projects, rather than frameworks or technical libraries, which are far easier to test (the developer is the domain expert at the same time). Actually no one answered the survey positively. But: is your real world, business project (=frequently changing requirements, lot of pressure, not academia) well unit-tested? If yes - drop me an email - you will be the first :-). But then I would like to see the tests as well.

Knowing the gap it is actually better to prescribe the testing of only the crucial things and expecti high quality here. 80%+ test coverage with crappy unit tests and green bars cause more damage, than use.

Why Schizophrenia Driven Design? Look at the definition: "...a mental disorder characterized by abnormalities in the perception or expression of reality. It most commonly manifests as auditory hallucinations, paranoid or bizarre delusions, or disorganized speech and thinking with significant social [teams] or occupational dysfunction. Onset of symptoms typically occurs in young adulthood,[1] with approximately 0.4–0.6% [this is not true in software engineering - I would say about 80% of projects are affected so far] of the population affected. Diagnosis is based on the patient's self-reported experiences and observed behavior [or retrospectives :-)]. No laboratory test for schizophrenia currently exists.... [except greenbars without asserts, but with 5MB System.out.println :-)]"

[see also "Real World Java EE Patterns - Rethinking Best Practices" book for examples and more detailed - pattern specific unit test discussion]