Think different about mock objects!

Recently, after the post on mock objects by Uncle Bob (“Manual Mocking: Resisting the Invasion of Dots and Parentheses”), a rather long discussion thread grown in the extreme programming italian newsgroup (starting here, but careful, it’s in italian, sorry!).
This led me to think more deeply about my experience with mock objects, and I’d like to share my point of view here, as it’s quite different (or so it seems to me) from the common opinions on this important topic.

I’ve always followed the so-called (as Giuliano would say, isn’t it Giuliano? :-) “English School” of mock objects, the one coming from the pioneering works of Tim Mackinnon, Steve Freeman and Nat Pryce, the real fathers of mock objects.

And I’ve always carefully followed their advice, first through their *epic* paper  “Mock Roles, not Objects” (http://www.jmock.org/oopsla2004.pdf) – IMHO the best paper on mock objects and on object oriented programming with mocks – then through their terrific posts on the blog www.mockobjects.com, and finally, through their first (and brand new) book, “Growing Object-Oriented Software, Guided by Tests”.

One thing I learn is that mock objects are a design tool, while many people see it only as a technique for speeding up unit tests.
And in this context mock objects are a key tool to support your TDD process, especially in test-driving your domain model, where you follow a process similar to traditional top-down development, in which you start from the highest level of abstraction and then proceed, layer by layer, to reach the core of the domain and then move again towards the boundary of the system, towards the “services” (you can find many similarities in Cockburn’s approach to Hexagonal Architecture).

Then, when you reach the domain boundary, you should stop using mocks.
Mock objects are useful to TDDing the thin adapter layers to your services (that is, third-party libraries or external components (e.g. a database, a JMS queue, …). But then, the actual adapters will be tested with integration testing.

Why?

Because you should use mock objects as far as you can apply TDD, whereas you can design and *discover* interfaces (and roles), and assign responsibility. On the other hand, in front of a third-party library you cannot follow this process, since the code is not under your control, and you cannot modify it.

Because if you use mock objects with third-party libraries (two concrete examples taken from our recent projects: isolating our tests from the database in a Rails app, or in a java app using Hibernate ORM), you’ll write tests that *guess* the library behaviour, and your guesses may be far away from the actual behaviour.
Raise your hands if you never burnt your fingers with this kind of test with mocks, where maybe you *thought* you had a save() method to return an A object while in fact it returned B object! :)

And finally, because this kind of tests with mocks end up to be long, unreadable and fragile (an “invasion of dots and parentheses” reported by Uncle Bob in his post), full of mocks and mock expectations. And, hey, you cannot refactor them, since you don’t own the third-party code!



To verify the correct integration with libraries or external components, which are out of you domain, as well as with integration tests, you may use fakes or stubs (and, by the way, the example in the Uncle Bob’s post is actually a stub, not a “hand-rolled mock”).

So, I’ll repeat myself, following this “mocks as a design tool” approach, you’ll mock only types you own.

Some useful references to study this topic in depth (you’ll be OK even if you read just the first 2-3 links :-)

I hope I give you some useful feedback on this topic!

And, by the way, feedbacks are warmly welcome!

Michael Feathers on TDD

Una breve riflessione di Michael Feathers sul TDD, passando per i mock objects per finire sulla necessita’ di adottare pratiche che “costringano” a ragionare e riflettere sul nostro codice.

Interessante anche l’excursus sulla storia dei mock objects, nati in Connextra

The story I heard was that it was all started by John Nolan, the CTO of a startup named Connextra. John Nolan, gave his developers a challenge: write OO code with no getters.  Whenever possible, tell another object to do something rather than ask.  In the process of doing this, they noticed that their code became supple and easy to change.

La frase chiave:

We need practices which help us achieve continuous discipline and a continuous state of reflection.  Clean Room and TDD are two practices which, despite their radical differences, force us to think with absolute precision about what we are doing.

Perche’ non si dovrebbero mockizzare classi concrete

Mi sono sempre chiesto perche’ mai Steve Freeman e gli altri ‘padri’ dei Mock Objects e dello stile di testing interaction-based sconsigliassero di fare mock di classi concrete, tanto che jMock ed EasyMock non supportavano questa possibilita’ ‘nativamente’, ma si doveva installare un’estensione a parte, che usa la famosa libreria CGLIB (per inciso con il nuovo jMock 2 e’ possibile fare mock di classi concrete, ma si deve usare la classe UnsafeHackConcreteClassImposteriser, ed il nome dice tutto di come scoraggino questa pratica).

Tanto che tempo fa avevo anche commentato un post di Freeman chiedendogli perche’ lui giudicasse il mock di classi concrete come una sorta di ultima possibilita’ da adottare solo in casi di emergenza (es quando si affronta codice legacy particolarmente ostico e chiuso). E lui mi aveva risposto cosi’:

Because then the interface is implicit, which means you can’t see it and you haven’t given it a name. Instead of using the test to expose a feature of the design, you have more to think about whenever you’re working in that area: is the method overwritten? is it in a super class? what about the state of the rest of the class I’m extending? That sort of thing.

For me, the CGLIB should have a “Break Glass in Case of Emergency” written on the front. It’s useful in tight situations, but not to be recommended.

Eppero’ nonostante la sua risposta la cosa non mi era ancora chiara fino in fondo.
Poi un recente post su mockobjects.com (Test Smell: Mocking concrete classes) mi ha finalmente aiutato a capire meglio le cose.

Il fatto e’ che lo scopo del TDD con i Mock Objects e’ quello di scoprire e far emergere relazioni tra oggetti, e dare nomi a queste relazioni. Se pero’ si mantiene la relazione tra oggetti a livello di classi concrete, queste relazioni rimangono per cosi’ dire piu’ nascoste, implicite, e quindi diventa difficile individuarle e darle un nome.

Cito direttamente il post, laddove spiega cosa non va con i mock di classi concrete:

The problem with this approach is that it leaves the relationship between the objects implicit.
I hope we’ve made clear by now that the intention of Test-Driven Development with Mock Objects is to discover relationships between objects.
If I subclass, there’s nothing in the domain code to make such a relationship visible, just methods on an object. This makes it harder to see if the service that supports this relationship might be relevant elsewhere and I’ll have to do the analysis again next time I work with the class.

Addirittura si spinge a dire che lasciando le relazioni tra oggetti a livello di classi concrete, si rischia di violare l’Interface Segregation Principle, perche’ le classi dipendono da una interfaccia piu’ grande di quella che usano veramente.

E poi poco piu’ avanti spiega che l’approccio mockist aiuta anche a dare nomi alle relazioni ed ai ruoli, e a ragionare piu’ in termini di dominio piuttosto che di implementazione:

There’s a more subtle but powerful reason for not mocking concrete classes.
As part of the TDD with Mocks process, I have to think up names for the relationships I discover—in this example the ScheduledDevice. I find that this makes me think harder about the domain and teases out concepts that I might otherwise miss.
Once something has a name, I can talk about it.

Il tutto e’ poi riassunto bene nell’altro post, What the tests will tell you, da leggere e rileggere, dove elenca alcuni benefici derivanti dall’approccio TDD+MockObjects

  • Keeping knowledge local
  • If it’s explicit I can name it
  • More names mean more domain information
  • Pass behaviour rather than data

Detto questo, ammetto che sono sempre stato affascinato da questo approccio ma non ho mai trovato la forza necessaria per decidere di applicarlo un po’ piu’ sistematicamente, metterlo alla prova insomma.

Un po’ perche’ nel mio team da sempre si usa l’approccio classico, e l’approccio interaction-based e’ visto con qualche dubbio/sospetto, un po’ perche’ i nostri progetti per ora sono tutti Java 1.4 e quindi buona parte delle comodita’ delle versioni piu’ recenti dei framework jMock e Easymock te le perdi (soprattutto la loro maggiore letteralita’, cosa importante per avere dei test validi).

Ascoltare i propri test: quando la lunghezza di un costruttore ci puo’ insegnare tanto…

Ancora una volta i post su mockobjects.com mi ricordano che c’e’ molto da imparare dai propri test. E’ il caso di Test Smell: Bloated Constructor e Test Smell: Everything is mocked.

Bloated Constructor…

Se si usa il TDD, capita di finire per avere oggetti con un costruttore gigante, che prende una lista infinita di parametri, tipicamente i peers (ovvero i collaboratori) dell’oggetto. In tali casi fare i test, e soprattutto farli coi mock, e’ la morte. E in molti casi ce la si prende coi mock, rei di complicare i test.

Ma spesso la difficolta’ a testare un oggetto e’ sintomo di problemi di design sull’oggetto stesso… E riflettere su queste difficolta’ e riportarle sul codice sotto test ci consente di migliorarne il design. O, come dice Steve Freeman, being sensitive to complexity in the tests can help me clarify my designs.

In questo caso un costruttore lungo potrebbe indicare che magari ci sono oggetti che potrebbero essere raggruppati a formare un nuovo oggetto. Questo semplifica anche i test dell’oggetto da cui siamo partiti e consente di ridurre le sue responsabilita’, tutte cose buone e giuste.

Freeman usa due euristiche per l’estrazione di componenti:

When I’m extracting implicit components, I look first for two conditions: arguments that are always used together in the class, and that have the same lifetime. That usually finds me the concept, then I have the harder task of finding a good name.

Nel secondo post che cito all’inizio, Test Smell: Everything is mocked, si sfata un mito duro a morire: non si devono fare mock per tutte le classi che si incontrano.

In particolare non e’ assolutamente necessario mockizzare value objects, e soprattutto “don’t mock third-party libraries!”. Piuttosto, un approccio migliore e’ quello di far emergere col TDD e i mock un sottile straterello di codice che faccia da adaptor verso le API esterne, e che fornisca al nostro dominio i servizi di cui ha bisogno.

E poi testare questo thin layer con dei test di integrazione che garantiscano che ci si agganci correttamente alla libreria.

Ascoltare i propri test, ovvero migliorare il codice partendo dagli smell dei propri test

Steve Freeman e Nat Pryce hanno iniziato una serie di interessanti post sul loro blog mockobjects sul tema dei Test Smells, ovvero su come ‘ascoltare’ i propri test per scoprire possibilita’ di miglioramento nel design del codice sotto test

In our experience, when we find that our tests are awkward to write, it’s usually because the design of our target code can be improved.

Una cosa su cui mi trovo d’accordo, piu’ che altro perche’ ho avuto la stessa esperienza in passato (e anche nel presente!)

Test Smells…

Il primo post della serie e’ Test Smell: I need to mock an object I can’t replace (without magic), dove si parte da un codice piuttosto ‘chiuso’, con dipendenze nascoste (magari usando dei Singleton), e passo passo lo si rifattorizza, aprendolo, prima introducendo un fake (o stub che dir si voglia) e poi passando ai mock, mostrando come il codice migliori, prima esplicitando le dipendenze e poi assegnando meglio le responsabilita’.

Se vi capita dategli un’occhiata!

Commenti al post “Don’t Over-Use Mock Objects” di K.Ray

Tempo fa Giuliano aveva segnalato questo post di K.Ray: Don’t Over-Use Mock Objects

Mi sembra che le tesi dell’articolo siano un po’ forti (“Avoid them. Mocks make your tests more fragile and more tightly-coupled. And at the same time, they reduce the integration-test aspects of TDD. They make your tests larger and more complicated and less readable.”). Certo, se usati male possono dare problemi di fragilita’ eccessiva del test e di leggibilita’ (a meno che non si usi un po’ di literate programming con jMock), e soprattutto se non si usano per riflettere su eventuali debolezze del proprio codice (a questo riguardo il blog su www.mockobjects.com fa spesso illuminanti esempi di codice che usa scorrettamente i mock).

L’obiezione che i mock ridurrebbero la robustezza dei test e’ debole (“If you change an object’s API, a mock object’s API may not change, making your tests out-of-date with respect to your non-test code”), perche’ con EasyMock si usano le API ‘vere’, pertanto non esite la possibilita’ di avere dei metodi ‘out of date’ (non so come funzioni invece jMock).

L’unica osservazione secondo me con un certo fondamento e’ la critica al modo di procedere degli interaction-based testers (“In TDD, you normally write a test, write some code in a target class/method that passes the test. The third step is refactoring. … Test-Driving with Mocks inverts that order: you create your target class and a mock class up-front, and plan on how they interact, instead of evolving that interaction in TDD’s refactoring steps. You pre-judge the class design rather than evolve it.”). Anche a me suona innaturale di norma procedere come gli interaction-based testers, ma penso anche che ci siano casi in cui questa ‘esplorazione’ delle interazioni e’ utile.
Suonera’ un po’ eccessivo, ma qualcuno diceva che la programmazione dei mock in un test e’ un po’ come un sequence diagram sotto forma di codice! :-)

Siamo invece d’accordo che i mock sono utili per rendere piu’ indipendenti i test (“Mocks are tool for decoupling, and I do sometimes use them. I limit my use of Mocks to those situations where the real object will not reliably do what I want. Examples: simulating errors in writing a file; simulating connections with a remote server; simulating errors from remote server.”).