Mocking

[Tom de Koning]

 

Hoi allemaal,

 

Rick, allereerst bedankt voor het organiseren van de meeting bij Sogyo.

 

Ik gaf al aan dat ik graag een tech onderwerp zou willen terugzien in de volgende meeting, mocking. Misschien dat het een goed idee is om een lijst van aspecten mbt mocking aan te leveren; discussie erover alvast op gang te brengen zodat het allemaal wat concreter wordt.

 

 

aspecten (ik baseer me nu op Rhino mocks):

Wat is het verschil tussen een mock en stub? in gebruik (volgens het rhino forum) is er geen verschil; ook op stubs kun je gedrag testen.

RhinoAutomocker; wie gebruikt het en wie niet (en waarom niet!)

AAA syntax vs klassiek mocken

 

Punt van Rick: dependencies die je in stand houdt juist doordat je mocked. Wanneer switch je naar een Observer, wanneer juist niet?

Wellicht lastig op te zetten, maar ik zou graag een klein voorbeeld willen zien van TDD waarbij gebruik wordt gemaakt van DI en mocking om uit te kristaliseren en je code uit te schrijven.

 

Voel je vrij om op deze lijst je commentaar te geven / aan te vullen.

 

Groeten Tom

 

 

[Rick van der Arend]

Hoi Tom, alt.netters,

Graag gedaan! En jij bedankt voor het thuisbrengen natuurlijk.

Mocking lijkt me een prima onderwerp voor de volgende keer. Hoeven we alleen nog maar een locatie en datum & tijd te hebben. :-).

Ernst, ik meen me iets te herinneren dat je ons uitnodigde bij Mirabeau in Amsterdam? Ben je trouwens inmiddels alweer beter? Jammer dat je er deze keer niet bij kon zijn.

Dat het onderwerp mocking bij ons de revue gepasseerd is, kun je trouwens ook hier lezen:
http://www.software-innovators.nl/2008/06/09/niet-mocken/

Dan nog even een vraag: ik zou iets online zetten, url's over een bepaald onderwerp. Wat was dat ook alweer? Heb het me proberen te herinneren, maar geen succes. Wie o wie kan dit ophelderen?

Leuk dat jullie er waren, vrijdagavond. Was weer interessant!

Groet,
Rick

2009/3/1 Tom de Koning <tomde...@gmail.com>

[Tom de Koning]

 

Naked objects linkje kan ik me herinneren.

Net de link doorgelezen; ben niet overtuigd. Juist door gebruik te maken van mocking zijn we in mijn laatste staat gebleken om complexe objecten en hun logica niet te hoeven doorlopen. Het argument van het instantieeren van het echte object komt er bij mij alleen al vanuit performance oogpunt niet doorheen (ik wil dat m'n tests snel draaien).

 

Over performance in tests gesproken: doordat we gebruik maken van Unity en LogWriter moest ik deze iedere keer uit de BootStrapper ophalen. Elke klasse had zijn eigen test klasse wat in veel gevallen inhield dat we de container moesten intantieren (wat traag is). Heeft iemand iets dergelijks ook ervaren of gewoon een oplossing out of the box? :-)

 

Groeten Tom

2009/3/2 Rick van der Arend <rvande...@gmail.com>

[Rick van der Arend]

Ok, nou, dat is niet zo moeilijk. :-)
http://www.nakedobjects.net/home/index.shtml

En voor instructievideo's:
http://www.nakedobjects.net/demo/demo_intro.shtml

Goed dat je niet overtuigd bent. Dan hebben we tenminste nog wat om over te praten volgende keer. :-) Overigens volg ik je even niet helemaal als je het hebt over het argument van het instantieren van het echte object. Dat doe jij neem ik aan ook? Maar je bedoelt waarschijnlijk de afhankelijke objecten?

Best practice wat betreft het ontkoppelen van dingen als Unity en LogWriter is volgens mij nog steeds deze laten injecten (liefst via de constructor) in productie. In de test kun je ze dan gewoon zelf instantieren en meegeven, heb je die container niet voor nodig. Of is dat in dit geval niet van toepassing, denk je?

Groet,
Rick

2009/3/2 Tom de Koning <tomde...@gmail.com>

[Tom de Koning]

 

Yep, daar doelde ik op idd.

 

Een LogWriter is lastig zelf te instantieeren, vandaar dat ik eigenlijk niet verder heb gekeken, maar gewoon m'n BootStrapper heb gebruikt. Omdat de performance nog best redelijk was (30sec voor alle tests) had ik 'm nog even geparkeerd in mijn todo lijst en was ik benieuwd naar jullie mening(en).

[Paco]

Dag Alt.nlers,

Ik ben nieuw hier.
Ik ben net als Tom er niet van overtuigd dat mocks niet nodig zijn.
Ik geloof best dat je "er omheen" kan programmeren, alhoewel het
natuurlijk een uitdaging is om hier wat code te posten waarbij het
niet kan...
Maar het lijkt mee geen goed idee de code van het te testen programma
anders te gaan schrijven met als enige doel het testen makkelijker te
maken. Je probeerd toch je programma zo goed mogelijk te schrijven en
als het dan ook nog eens gemakkelijk te testen is, is dat mooi
meegenomen.
Ik vraag me af: wat is er tegen mocks? Het zou kunnen dat ze niet
nodig zijn, maar dat betekent niet dat ze niet handig zijn!

Over het verschil tussen mocks en stubs kan je lezen op de volgende
link:http://martinfowler.com/articles/mocksArentStubs.html
Naar mijn mening zit het verschil tussen mock en stub meer in je hoofd
dan in een mocking-framework. Ik gebruik zelf Moq waarbij in de syntax
geen verschil wordt gemaakt tussen een mock en een stub.

Automocking is wat mij betreft een aanrader. (waarom heet het
eigenlijk geen autostubbing?) Het scheelt een hoop werk en het is
gemakkelijk te leren.

@Tom: Ik ken de argange, act, assert maar wat wordt er met "klassiek"
mocken bedoeld?

groeten,
Paco

[Paco]

[Paco]

[Arjan Zuidhof]

interessante discussie!

Bij nieuwbouw ligt wel/niet mocken imho wat anders, maar stel nu de situatie de volgende is: je erft een bak legacy code (waarbij ik hier de definitie even stel op code die zonder tests/TDD geschreven is en waarbij SOLID/OO principles behoorlijk geschonden worden). De applicatie dient van nieuwe features te worden voorzien, en krijgt vanuit productie nog regelmatig bugs aangemeld. Wanneer de applicatie nog een behoorlijk business value genereert, en er niet de gelegenheid is om grote refactor slagen toe te passen, zou ik menen dat mocks juist de redding van je project zijn. Een purist zou nu zeggen "je moet refactoren, en daarin niet toegeven" maar de echte wereld is niet zo schappelijk. Daarnaast bestaat natuurlijk het gevaar dat bij al te wild refactoren in een slecht ontworpen codebase zonder initiële tests je de werking van die stukken code onbedoeld verandert. Je wilt natuurlijk niet dat dit pas in productie blijkt...

Komen jullie deze situatie wel eens tegen -ik dus wel ;-( - en zou je dan nog steeds niet voor mocks kiezen? Ik ben erg benieuwd. Ook omdat voor mij mocking een relatief nieuw onderwerp is moet ik eerlijk zeggen, en ik graag zie hoe anderen daarmee omgaan.

Arjan

2009/3/2 Paco <pac...@gmail.com>

[Rick van der Arend]

Hoi Paco,

Zelf zou ik niet zover willen gaan door te zeggen dat mocks helemaal niet nodig zijn. Ik denk wel dat ze een koppeling tussen verschillende classes/objecten aanduiden. En een eerste reactie daarop zou moeten zijn: kan ik die koppeling eruit krijgen? Dit maakt over het algemeen je code eenvoudiger te begrijpen, beter onderhoudbaar, beter herbruikbaar, etc. Alle voordelen van lage koppeling, zeg maar.

Standaard oorzaken die kunnen zorgen voor een hogere koppelingsgraad zijn verkeerd (of niet) gedefinieerde verantwoordelijkheden voor de verschillende objecten/classes en de verkeerde plaatsing van een methode, die dan eigenlijk beter geplaatst zou kunnen worden op het object waar de methode gebruik van maakt. Het simpelweg mocken van die dependencies, automocken zelfs, kan ervoor zorgen dat je de mogelijkheden voor ontkoppeling niet onderzoekt.

Verder denk ik dat het verschil tussen mocks en stubs weer een typisch geval is van: technisch (vrijwel) geen verschil, functioneel echter zeker wel. Beide zijn het uitgeklede varianten van een class/object die als stand-in dient voor het 'echte' type. In statische talen wordt dit vaak bereikt door dezelfde interface te ondersteunen of van het doeltype af te leiden. Echter, een stub is volgens mij bedoeld als stand-in tijdens de eerste fases van prototyping en deployment. Je wilt een repository in het uiteindelijke product, je wilt ook zo kunnen programmeren alsof hij er al is en gaat blijven, echter, de echte variant is nog in productie/bestelling. Je kunt dan een stub maken die functioneel geen of weinig (bijvoorbeeld serialization ipv opslag in relationele db) van de uiteindelijke functionaliteit biedt, maar er wel voor zorgt dat de latere plaatsing van de bedoelde repository een fluitje van een cent is.

Een mock is mijns inziens een variant daarop, die je met name tijdens unit-tests gebruikt. Een mock bevat een script van te verwachten aanroepen en terug te geven resultaten die daarmee de interface tussen het object-onder-test en de mock testen.

Groet,
Rick

2009/3/2 Paco <pac...@gmail.com>

[Paco Wensveen]

Hoi Rick,

 

Als je de koppeling niet op een member van een class plaatst, maar tussen methods bestaat de kopelling nog steeds. Het is alleen minder object-georienteerd met proceduele code geworden. Lage koppeling blijft natuurlijk belangrijk, maar software met te weinig koppeling is ook waardeloos. Soms kies je daarom bewust voor strakke koppeling in plaats van lossere koppeling met interfaces.

Ik gebruik zelf ndepend (http://www.ndepend.com/) om koppeling te analyzeren (dowload de demo als je het nog niet kent).

 

Stubs kunnen op 2 manieren gebruikt worden:

- zoals jij beschreef door tijdens de ontwikkeling een repository met relationele database te vervangen door een "nep" database met serializatie

- in tests om dependencies te vervangen door een implementatie die niets doet, behalve bepaalde waardes teruggeven, zodat alleen de class onder test getest wordt en niet het hele programma.

 

Het verschil tussen een mock en een stub binnen tests is dat er op een mock ook bepaald gedrag of wijzigingen van staat zijn te verifieren.

 

Groet,

 

Paco

2009/3/2 Rick van der Arend <rvande...@gmail.com>

Hoi Paco,

[Tom de Koning]

 

Welkom Paco!

 

Een voorbeeld waarbij het gewoonweg niet kan is Sharepoint. Daar hebben we al levendige discussies over gehad afgelopen vrijdag, maar qua testbaarheid werkt het niet echt mee. Het dwingt je om een test "live" tegen je omgeving uit te voeren. 

 

Met klassiek doel ik op de mock.Record() en mock.Replay() syntax.

 

Tom

 

2009/3/2 Paco <pac...@gmail.com>

[Paco Wensveen]

Dag Tom,

 

Ik heb geen ervaring met sharepoint, maar kun je geen wrappers om de classes bouwen die niet los te koppelen zijn?

Ik doe dit zelf met web-projecten voor bijvoorbeeld httpcontext en iprincipal

 

aan mock.Record() syntax van rhino mocks heb ik niet kunnen wennen, daarom ben ik met moq begonnen. Inmiddels heeft rhinomocks ook dezelfde syntax en is er weinig verschil meer tussen rhino en moq voor zover ik weet.

Paco

2009/3/2 Tom de Koning <tomde...@gmail.com>

[Tom de Koning]

Nope. Je kunt er wel omheen met TypeMock, maar dat was nou net het punt :)

 

 

2009/3/2 Paco Wensveen <pac...@gmail.com>

[Rick van der Arend]

Hoi Paco,

Overigens leuk dat je aan de discussie meedoet. Hoe ben je bij ons aanbeland? Ik zou zeggen: kom de volgende keer ook eens langs, zeker interessant aangezien je zeker een doordachte mening over het onderwerp lijkt te hebben.

Om nog even op jouw onderstaande mailtje in te gaan.. Het verschil tussen het plaatsen van een koppeling op een member of method van een class moet je even uitleggen. Bedoel je dan misschien op een property of method? In ieder geval lijkt me dat inderdaad weinig verschil maken. Maar ik geloof niet dat ik hier helemaal door hebt wat je probeert te zeggen. Zou je dat nog uit kunnen leggen?

Wat betreft jouw uitleg over de stubs, denk ik dat wat je beschrijft vrijwel hetzelfde is. Je geeft echter aan stubs ook regelmatig in unit tests te gebruiken. Lijkt mij verder prima.

Met vriendelijke groet,
Rick

2009/3/2 Paco Wensveen <pac...@gmail.com>

[Mendelt Siebenga]

Ik let even niet op en er is hier een hele discussie op gang gekomen, leuk! :-)

Volgens mij is het belangrijke onderscheid hier state based testing vs behaviour based testing. In beide gevallen kan je gebruik maken van mocks of stubs, de technische implementatie hiervan is voor dit onderscheid niet zo interessant. Wat wel interessant is is hoe je je verificatie doet aan het eind van je test.

Bij behaviour based testing kijk je of de te testen code de juiste calls heeft gedaan naar omliggende code.

Bij state based testing kijk je of de te testen code de juiste state heeft achter gelaten.

Ik gebruik beide maar neig naar state based testing als dit mogelijk is. In de meeste gevallen zijn dit soort tests leesbaarder en minder fragiel. Wijzigingen in de implementatie van de code zorgen minder vaak voor falende tests.

Overigens is er bij rhino mocks wel degelijk verschil tussen stubs en mocks, maar de verschillen liggen meer in default gedrag. Properties op een stub gedragen zich bijvoorbeeld default als een property. Stop je er iets in dan komt het er ook weer uit. Properties op een mock moet je expliciet instellen.

Ik heb ook het niet mocken artikel van de sogyo'ers even gelezen. Ze splitsen een functie die gebruik maakt van een data access layer zodat het gedrag wat ze willen testen in een losse functie terrecht komt. Deze functie maakt nog steeds gebruik van een data object. Dit object zou ik met een mocking framework gemaakt hebben. Ook schrijven ze dat de functie die de data uit de dao haalt en de 2e functie aanroept niet meer getest hoeft te worden omdat deze geen gedrag bevat. Dit vind ik ook wat kort door de bocht. Een echte applicatie bestaat voor 75% uit dit sooft code, deze is vast en zeker niet helemaal foutloos en unit tests zijn uitermate geschikt om dit sooft fouten op te sporen.

groeten,

Mendelt

Op 2 maart 2009 23:38 schreef Rick van der Arend <rvande...@gmail.com> het volgende: