http://www.google.no/search?q=crud+moq+repository&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:nb-NO:official&client=firefox-a

og en kollega dukker opp blandt de første treffene!

Når det gjelder begrepsforvissingen så er jeg enig med @kzu – utvikleren bak moq – da han sier at det egentlig ikke gir noen spesiell verdi å kunne skille mellom mocks, fakes, stubs, etc. Se min siste post: http://blog.kjempekjekt.com/2009/08/27/avhengighetsisolering-aka-mocking-i-net/

Par kommentarer: Utenfra-og-inn-programmering fungerer like bra på API-er, web tjenester eller hvilken som helst kode. Det er ingen forutsetning at det du lager har et brukergrensesnitt. Og gjennom å skrive testen først, er du hele tiden en “klient” av koden du skal skrive, og på den måten kun implementerer det som strengt tatt er nødvendig. Så teknikken kan like gjerne brukes om du skal lage et API for å snakke med Twitter, eller en GUI applikasjon.

Kommentar to: Det er en god del forvirring rundt begrepsbruken Mock, Fake, Test-Double, Stub osv. Jeg velger å følge Roy Osherove’s beskrivelse fra NDC. Alt er en stub inntil du gjør en assert. Da blir den en Mock. Og du skal kun ha en Mock per test (en logisk Assert).

Så dvs. at Mocking vs Stubbing handler ikke så mye om hvilken “teknologi” eller verktøy du bruker, men snarere hvilken rolle objektet får når testen kjøres. De objektene du gjør assert mot blir mocks, de som spiller på lag for å returnere fake data er stubs.

På prosjektet jeg jobber på nå skriver vi alle Mockene våre for hånd. Det er enkelt, lett og forstå og fleksibelt. Vi bruker public fields for å styre oppførsel.

F.eks “KunderSomSkalReturneres”, “HentKundeBleKalt”, eller “SkalKasteException” osv.

Jeg vil også skrive meg inn i fanklubben din! Det er morsomt å lese dine poster. Du er flink til å skrive og kommunisere ditt budskap. Stå på!

Jeg er også en stor fan av utenfra-og-inn fremgangsmåten, og bruker det selv flittig når jeg utvikler systemer med grafiske brukergrensesnitt. Jeg er helt enig med deg i at dette er en god fremgangsmåte for å oppdage avhengighetene – utenfra og inn, men det er ikke hovedgrunnen til at jeg selv jobber på denne måten.

Jeg jobber utenfra-og-inn er på grunn av kunden. Kunder flest oppfatter datasystemer som brukergrensesnittet han/hun ser på skjermen. I mange tilfeller bryr de seg ikke om hvordan database som brukes, om det er 3-lags arkitektur, om det er tjenester (SOA), programmeringsspråk, platform osv. Selvsagt er det unntak, men de ødelegger poenget mitt:p Hvis jeg begynner med brukergrensesnittet, kan jeg ta kunden med i feedback loopen fra dag 1. Allerede etter noen linjer med programmering har jeg noe å vise frem til kunden – noe som kunden også forstår, nemlig skjermbilder. Jeg behøver ikke å si til kunden: du må vente en eller to måneder, for vi jobber med å få på plass ”arkitekturen”. Dette stimulerer til tettere samarbeid mellom leverandør og kunde, og minsker risiko. Kunden behøver ikke ”brenne” to måneder med utvikling for å se den første funksjonaliteten. Selvsagt er arkitektur viktig, men alt behøves ikke å gjøres up front – den kan også vokse organisk mens vi utvikler programvaren.

Når det gjelder persistence ignorance er jeg helt enig. Jeg personlig, begynner ALDRI med relasjonsdatabasen. Jeg tenker ikke engang relasjonsdatabaser – jeg tenker persistering. Men jeg må vell også nevne at jeg i de fleste tilfeller jobber med OO :) Relasjonsdatabaser har sine bruksområder.

Mocking er nyttig for å isolere avhengighetene, men ikke den enste måten å gjøre det på. Jeg har også gode erfaringer med å skrive FAKE implementeringer som benyttes i stedet for MOCK objekter. Da er det enklere for mindre erfarne utviklere å forstå hva som foregår. Jeg er helt enig med Johannes at MOCKs er for viderekommende. Dersom jeg jobber i et team med utviklere som ikke har erfaring fra TDD og mocking, begynner jeg forsiktig med å introdusere dem for FAKE implementeringer før MOCKs.

Vi drives helt klart av forretningsbehov. Det er prosjektenes sponsorer (stakeholders) som sitter på pengesekken, og vi må gjøre som de vil. Det er ikke uvanlig at disse er ambivalent, og ønsker endringer fortere enn vi rekker å implementere eksisterende krav. For at vi som utviklere skal klare å være fleksibel ovenfor våre sponsorer, må vi ha en fleksibel kodebase. For å få en fleksibel kodebase så er TDD, BDD og mocking gode ”verktøy”. For å oppdage endringer tidlig er utenfra-og-inn en veldig god taktikk.

Gøran

Det finnes ikke noe klart svar på dette, hvor mye design som er fornuftig eller ikke, uten å ta hensyn til kontekst.

Vår oppgave som utviklere er å lage kode som kommuniserer godt, lage gode abstraksjoner. Er ikke et design med ti klasser potensielt dobbelt så kommunikativt som et design med fem klasser? Etter min erfaring er underdesign et større problem enn overdesign, og jeg setter faktisk pris på kode som den du viser i kommentaren. Kan du si noe mer om hvorfor dette er dårlig design?

Kanskje jeg har gått for langt. Jeg vet ikke.., jeg endrer/utvikler jo både min egen oppfatning og fremgangsmåte hele tiden, så det er vanskelig å være alt for bastant når man ikke får erfaring med å gjør det samme over lang tid (selv om jeg ikke lar det stoppe meg fra å hardnakket argumentere for mine meninger). Det er derfor jeg liker så godt å blogge, sånn at jeg kan få testet mine erfaringer og meninger ut i den store verden.

Her ender man opp med store mengder mocking, men det er ikke så ille. Det som er ille er kode som minner om ting jeg har sett i min egen kode når jeg mocker:

public class Guitar {

public List notesPlayed = new ArrayList();

public void play(Tab tab) {
notesPlayed = tab.notesToBePlayed();
}

}

public class Tab {

private final List notes;

public Tab(String asciiTab,
TabParser parser) {
notes = parser.parse(asciiTab);
}

}

Her har først Tab og så TabParser vært mocket. De er naturligvis bare flesk i dette designet. Sløsing. Muda!

Dette er tulleeksempler, men gjenspeiler kode som er skrevet av uerfarne eller overivrige mockere. Mocking er for viderekommende, og bør ikke brukes før du virkelig vet hva du holder på med!

Hva skjer med din approach om du ikke har en lineær avhengighetstruktur, men har et voksende tre med avhengigheter? La oss si at du skal lage en kontroller som har fire avhengigheter. Og hva om disse igjen har flere avhengigheter? Da vil du ikke få noen feedback på om det du har gjort på toppen er riktig før alle disse avhengighetene er implementert – og det kan ta lang tid. Jeg foretrekker å gå i små steg med mye tilbakemelding – jeg tror det bør skalere bedre når kompleksiteten øker.

UPDATE: Jeg har en kommende post hvor jeg demonstrerer TDD i praksis. Håper du leser den, hvor min fremgangsmåte skal komme klart frem.

Du sier at jeg ikke skal sage systemet i to. Jeg vil påstå at det er hele poenget med objektorientering: Splitt opp systemet ditt i små, autonome enheter, som kan sammarbeide om å få jobben gjort. Hver enhet er et lite program som gjør én ting, og gjør den godt. Da føles det helt greit for meg – ja, jeg vil faktisk si filosofisk riktig – å utvikle enhetene i vakum, sålenge kravspesifiksjonen til enheten allerede er drevet frem av kodeeksempler/tester.

Enkelte har påpekt et skille mellom det de kaller klassisk TDD (eller State TDD) og \”mockist TDD\”. I klassisk TDD sies det at man er opptatt av å verifisere tilstandsendringer, og at man bruker mocks kun der hvor det i praksis er vanskelig eller tungvidt å bruke de faktiske implementasjonene. Mockist TDD fokuserer mer på å teste interaksjonen mellom objekter. For meg betyr det at denen formen er mer opptatt av adferd, som er en god ting. Martin FOwler sier (i Mocks Aren\’t Stubs) at BDD er et \”offshoot\” fra mockist TDD.

Så det virker altså som om du står for en mer klassisk TDD (og da har du muligens flest på din side), mens jeg \”reklamerer\” for BDD (gjengen med mest momentum for tiden). Er du enig i det?

Takk for en solid kommentar.., jeg liker debatten!

To essensielle punkter:
* Start med brukerhistorien
* Ta ansvar fra topp til tå av arkitekturen – altså: ikke sag systemet i to

Men jeg har aldri likt mocking selv. Jeg bruker en annen innfallsvinkel. Her er eksempel fra dagens kodesesjon:
* Vi skal søke etter kontoer basert på navn og adresse
* Vi lager en test som sier “gitt at x, y og z finnes i basen (dvs: legg x, y og z i en blank in-memory base), når brukere fyller ut navn slik og adresse slik, og brukeren trykker på ‘søk’ knappen, så skal x finnes i tabellen”
* Testen feiler naturligvis voldsomt.
* Vi koder det som skal til på brukergrensesnittet til vi kommer til at vi har skrevet “Repository.find(KontoSpecification.medNavnOgAdresse(…))”
* SÅ SETTER VI DENNE TESTEN TIL IGNORE og starter å jobbe med en test mot repository-nivået
* Tilsvarende med andre deltester

Resultatet er at vi har en system som er koblet samme fra topp til tå, med utgangspunkt i brukerhistorien. Men vi har hatt en test som har feilet (eller vært kommentert ut) i 30-60 minutter! På den andre siden har vi færre indireksjonslag, fordi vi har brukt mindre mocking.

Å kommentere ut toppnivåtesten framfor å mocke den gir altså en fordel i at man unngår mocking. Men det gjør at vi har feilende tester veldig lenge. Hva tror du? Er det en ok innfallsvinkel? Bedre, dårligere?