When I want to rescue legacy code, I reach for Mockito. When I want to design for new features, I reach for JMock.

By default, JMock assumes that a test double (a “mock”) expects clients not to invoke anything at any time.


On the other hand, Mockito assumes that a test double (sadly, also a “mock”) allows clients to invoke anything at any time.


When I work with legacy code, I mostly write learning tests to discover how different parts of that legacy code behaves. Usually legacy code has obscene and overwhelming levels of interdependency, and Mockito helps me manage that, by allowing me to worry about one crazy dependency at a time.

When I design for new features, I mostly write design tests that describe the new behavior I want to implement. With the nice green field of a new interface, I need JMock to encourage me to clarify the interaction I need. Whenever my production code attempts to use a collaborator, JMock effectively reminds me to ensure that I want that interaction. Most importantly, JMock stops me from introducing dependencies that I don’t need.


Mockito helps me tolerate high accidental complexity while I work to reduce it.

JMock tries its best to stop me from introducing accidental complexity.

The book “Growing Object-Oriented Software Guided by Tests”, written by distinguished London programmers Steve Freeman and Nat Pryce, illustrates the “London school” approach centered on strict application of the Dependency Inversion and Interface Segregation Principles, which involves heavy and highly-effective use of test doubles.

Detroit-adjacent programmers Ron Jeffries and Chet Hendrickson (along with several non-Detroit-adjacent programmers like Joshua Kerievsky, James Shore and Arlo Belshee) exemplify the “Detroit school” approach which centers on a more intuitive and direct application of the Four Elements of Simple Design, in which they avoid test doubles and use the resulting tension to guide them towards designs that better reflect the Single Responsibility Principle.


The London school approach feels more like methodical, safe, steady design, whereas the Detroit school approach feels more exploratory or meandering (in the good sense, like wandering through a garden, unworried about the path, trusting that I’ll get where I need to go).

Some critics of the Detroit school dislike the feeling of having to forget what they already know about design and re-discover everything from first principles; some critics of the London school feel that test doubles lock their design in and resist change.

I see it another way: the Detroit school allows me to meander safely when I have a general idea of the destination, but an unclear picture of the route; the London school encourages me to build tiny things and put them together, and when I find that a piece needs to change shape, I can throw that piece away and design a new one in its place without paying a prohibitive cost for it.

I think of the London school approach as a shortcut that I can take when I think I recognise what I need to build and the Detroit school approach on which I can fall back when I just don’t know what to do next.

J. B. Rainsberger on London and Detroit schools of TDD in his book Responsible Design for Android, quoted by Phillip Scharz in the in the GOOS mailing list

Indeed you really ought to throw a non-deterministic test away, since if you don’t it has an infectious quality.

If you have a suite of 100 tests with 10 non-deterministic tests in them, than that suite will often fail.

Initially people will look at the failure report and notice that the failures are in non-deterministic tests, but soon they’ll lose the discipline to do that.

Once that discipline is lost, then a failure in the healthy deterministic tests will get ignored too.

At that point you’ve lost the whole game and might as well get rid of all the tests.

Martin Fowler on the infectiousness of non-deterministic tests in his article Eradicating Non-Determinism in Tests