Där jag jobbar nu mockar jag ungefär en gång i veckan. Nästa vecka kör vi vårens fjärde möte i JDojo@Gbg och temat för denna gång är just mockning. Vi kommer använda Mockito som jag tycker är mer lättanvänt verktyg än t ex EasyMock. En fråga som alltid dyker upp efter att man petat lite på ämnet brukar vara ”Vad är skillnaden mellan en stub och en mock?” I Mocks Aren’t Stubs har Fowler summerat det ganska bra tycker jag:
- Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
- Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
- Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ’sent’, or maybe only how many messages it ’sent’.
- Mocks are [...] objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
Mockist Approach vs Stubborn Approach
Detta är ett känsligt ämne – att påstå något om något som någon identifierar sitt arbete med. Jag brukar hävda att med stubborn approach (dvs när man bygger stubs eller fakes för sina collaborators/samarbetsklasser) så tenderar man att tappa fokus när man flyttar sin testverksamhet mellan olika klasser. Att använda en Mockist Approach (dvs när man mockar samarbetsklasserna runt sin ”enhet under test”) skulle på så sätt kunna hjälpa till att bibehålla fokus på den klass man utvecklar.
Detta påstående brukar väcka lagom mycket anstöt för att få igång en givande konstruktiv diskussion där erfarenheter delas mellan debatörrer. Vad betyder det t ex när ett test med ett mockat beteende fallerar, jämfört med att använda en stub som kanske kan vara den verkliga (enda) implementationen?
