The fourth principle is relevant for empowering project teams:
|Ensure pattern implementations are conveniently testable to encourage frequent running of the complete test suite using functionally equivalent services.|
Based on our experience with “the Company,” we encourage a JUnit Strategy for Testing (JUST-enough) approach, which seeks to: minimize external dependencies, leverage functionally equivalent services, minimize the use of Mocks except for reluctant collaborators, and encourages running the full suite of tests frequently.
We have observed the continuing tension between the Classical style of TDD and the Mockist style that Martin Fowler described in 2007. We believe that an irrational exuberance for mock testing can lead to a disproportionate ratio of test operations to production code operations. This ratio can serve as an “exuberance smell” for the potential elimination of test code waste (duplication) and encouragement to design with proven patterns demonstrating simpler testability.
So, when does JUST advocate using a Mock resource? Oleg Shvartsman has provided a wonderful answer to this question by injecting the term “Reluctant Collaborator” into the discussion. Oleg defines the term as when a resource is:
- not yet available
- not yet stable
- has access policies hindering availability
- slow to respond
- otherwise inconvenient to use
We also advocate pursuing creative techniques for indirect testing of production code to minimize duplication. In the following excerpt (“Uncle Bob”, 2013) discloses when he does not practice TDD:
So, when do I not practice TDD? I don't write tests for getters and setters. Doing so is usually foolish. Those getters and setters will be indirectly tested by the tests of the other methods; so there's no point in testing them directly. I don't write tests for member variables. They too will be tested indirectly. I don't write tests for one line functions or functions that are obviously trivial. Again, they'll be tested indirectly.
Generally, the more modular the code the greater the opportunities for indirect testing of “trivial” functions.
The JUST-enough approach features Functionally Equivalent services, thereby enabling execution in a production-like context without requiring a Java application server. Test performance typically degrades when exiting the JUnit JVM. Here are some examples of functionally equivalent services sustainable inside the JVM:
- CDI container
- in-memory databases
- JAX-RS RESTful clients/server
- JPA persistence engine
- JNDI tree
- security subsystems
This figure shows a JUnit Java Virtual Machine (JVM) with a portable CDI container, in-memory database and JAX-RS RESTful client.
The JUST-enough approach seeks to match the historical performance advantage that testing with mock resources has enjoyed. Functionally equivalent services also enable execution without network connectivity, thus mitigating one of the many challenges of globally sourced anywhere/anytime development.
As mentioned previously, it is typical for teams committed to TDD to forego direct testing of getter/setter (accessor/mutator) methods in favor of indirect testing. Beginning in 2006, Todd’s team began experimenting with a JUnit based tool, TestUtil, to provide direct testing of an entire application with a single line of test code.
With indirect testing, coverage of getter/setter methods is haphazard. On the other hand, direct testing enables commensurable code coverage metrics. That is, measurements of code coverage are comparable because they use the same standard.
Teams with the best of intentions may fall short of their aspirations when delivery pressures mount. Metrics reported on “big visible charts” or “information radiators” help sustain a culture of accountability to those aspirations. When the radiator shows that coverage metrics slip out of the ideal range, this fact is made more difficult to ignore, and encourages the team to refocus.
 In 2002, Java was adopted as the standard platform for in-house development at a successful large automotive manufacturing enterprise (“the Company”).
 Fowler, Martin 2007. Mocks Aren’t Stubs. http://martinfowler.com/articles/mocksArentStubs.html
 Todd Hall was technical lead and architect for the original 2004 team launching the PED journey.
 This refers to Marvin Toll’s open source TestUtil 2.0 project, circa 2006.
Martin, Robert C. 2013. The Pragmatics of TDD.