Som jeg har sagt tidligere, jeg ser ikke hensikten med å skille konseptene så sterkt i praksis. “Teststuntmennene” jeg bruker er som regel både stubs og mocks på en gang, og hvis jeg forstår hva du mener med “spies” (første gang jeg hører om dem) så er de gjerne det også. Poenget er at de er stand-ins for avhengigheter som lar meg kjøre koden i en klasse, og verifisere at den gjør som forventet. Som utvikler trenger jeg ikke mer enn det.., resten er kun av akademisk/filosofisk interesse – interessant, men ikke praktisk.

Test Doubles kan være et greit samlebegrep, om vi ser bort fra at enkelte ikke har lyst å snakke om tester i det hele tatt (the BDD / Code-by-example crowd). Dessuten kan fakes og mocks være nyttige teknikker andre steder enn i tester, som ved prototyping, eller før man integrerer løsninger mot eksterne systemer. For meg er “Mocking” fortsatt det ordet utviklere flest har hørt noe om, og vi kaller verktøyene for mockingrammeverk, så den pragmatiske løsningen er å bruke det.

Når det kommer til fallgruve nummer 1 så er jeg enig – det er absolutt en fare for at man kan overspesifisere forventningene. Jeg er derimot ikke helt sikker på at denne faren er større når man bedriver mockist TDD enn om man driver med klassisk (state) TDD. [Se min kommentar på utenfra-og-inn programmering for mer om de begrepene.] Når man mocker (les: bruker mange test doubles) har man en sterkere tendens til å spesifisere forventninger knyttet til adferd, kontra det å knytte forventninger til tilstandsendringer. Jeg skal ikke påstå at det er enklere å trå feil med tilstandsforventninger, men jeg TROR det er det. Trenger å jobbe mer med problemstillingen.

Fallgruve nummer 2 fikk meg til å tenke litt, men jeg tror ikke det er et problem som kommer som en følge av å bruke mocking. Hvis designet følger ISP og SRP så vil mockingen følge ISP og SRP. Og jeg er av en klar oppfatning at utenfra-og-inn programmering vil hjelpe deg til å følge disse prinsippene. Mocking gjør det klart enklere for meg å følge SRP, det er helt sikkert. Og ikke bare SRP i designet, men også SRP under utvikling – ved at jeg kan konsentrere meg om ett ansvar om gangen, og mocke resten. Når jeg koder utenfra-og-inn er det nettopp “roller” jeg oppdager, ikke objekter. Objektene kommer i neste rekke, når jegbevegere meg nedover i avhengighets-treet.

Jeg forstår ikke hvorfor du synes konfigurerbare, manuelle stubs, fakes og spies gir veldig mye bedre kode. Kanskje er det en smaksak, men et mockingrammeverk gir mindre kode å vedlikeholde, kommuniserer godt om det brukes riktig, og koblingen mellom testen og test-double blir tettere.

Til slutt et lite forbehold: Jeg har ikke mocket lenge nok til å se hvilken effekt det har på testene mine over lang tid – når designet endrer seg drastisk. Det kan godt tenkes jeg er skyldig i å låse implementasjonen mer enn jeg burde. I så fall gleder jeg meg til den dagen jeg oppdager det, for da har jeg lært noe. Mocking har brakt min TDD-teknikk til et nytt nivå, men det er LANGT igjen til fullstendig mestring – om det i hele tatt er mulig å oppnå.

Igjen, takk for at du deler dine tanker og meninger!

Jeg syns vi skal være konsekvente og bruke Test Doubles som et samlebegrep (som Johannes bruker over) for Test Stubs, Test Spies, Fake Objects og Mock Objects. Gerard Meszaros har laget en fantastisk god samling i sin bok XUnit Test Patterns (se også http://xunitpatterns.com/). Jeg ser ikke begrepsforvirring som noe unnskyldning for å ikke å bruke fornuftige og beskrivende begreper, som atpåtil er beskrevet detaljert i en koloss av en bok (størrelse og kvalitet)! Hvis vi som kan litt om dette ikke kan bruke et felles begrepsapparat er det ikke rart Olsen i gata ikke helt får grepet om det hele. Stubs kontrollerer indirekte inndata, spies kontrollerer indirekte utdata og fakes er reelle, men alternative, kjappere og/eller sideeffektfrie avhengighetskomponenter. Hva mocks legger på er selvsjekking. Jeg vet ikke hvorvidt dette sammenfaller med hva bl.a. Roy Osherove skal ha sagt om saken (som er nevnt i kommentarer i din forrige post). I en intern presentasjon hos oss brukte jeg henholdsvis de norske begrepene teststuntmenn, teststubber, testspioner og bedragere for de 4 første. Du er god med ord, hva ville du foreslått?

Det er hvertfall 2 store farer jeg har erfart med mock objects (i Meszaros’ betydning) og da spesielt når man benytter 3. parts rammeverk for jobben. Den første feilen er å overspesifisere forventningene og låse implementasjonen. Det er en sammenheng mellom å ikke helt forstå rammeverket og feil nummer 2. Feil nummer 2 er knyttet til mange elementer, men manifester seg i at man mocker hele objekter og ikke roller (se “Mock Roles, Not Objects” http://www.jmock.org/oopsla2004.pdf). Dette gjør det ekstremt enkelt å bryte med ISP og SRP.

Etter at vi virkelig tok innover oss ISP (ev. Role Interfaces (Fowler))(for ikke å snakke om skikkelig objektorientering!), så ble også behovet for Mock Objects og tilhørende rammeverk mer overflødig. Så på et vis dekket de over et problem vi hadde som ikke kom til overflaten fordi vi brukte et slikt rammeverk. Vi lager oftere nå konfigurerbare manuelle stubs, fakes og spies, da implementasjonen av disse nette interfacene ikke er store jobben, og vi får veldig mye bedre kode. Vi har sakte men sikkert begynt å bruke mer Mock Objects igjen, men de er i mindretall.

Har sett over kommentarer i din forrige post om temaet nå og ser at dette godt kunne vært postet der, men nå ble det her i stedet!

mvh
Morten (haugern@twitter)

For Java-programmerere det ute: Innen Java har jeg i det siste brukt rammeverket Mockito. Dette har en veldig konsis og typesterk syntaks og oppfordrer til å ikke spesifisere mer oppførsel enn det som er nødvendig, slik at testene blir mer robuste.

Mockito minner en del om Moq, men er litt mer konsist og magisk når du spesifiserer et metodekall. Så ditt Login-eksempel blir:

LoginView view = Mockito.mock(LoginView);
Mockito.when(view.getPassword()).thenReturn(“passw0rd”);

UserRepository repository = Mockito.mock(UserRepository);
Mockito.when(repository.findByName(Mockito.any())).thenReturn(new User(“BED128365216C019988915ED3ADD75FB”));

Med static imports blir det enda mer sveet.