Postade igår kväll följande till Agile Swedens mailinglista som svar på denna fråga:

Sitter och skriver en simpel liten besöksräknare för Asp.Net. En av metoderna i en av klasserna tar emot en HttpRequest, kollar referrer och lite annat och sparar i en databas.

Innan jag skriver metoden vill jag skriva ett test. Då vill jag skapa ett Mock Object som kan ersätta HttpRequest-objektet i själva testet, men se det går inte för HttpRequest är sealed och går inte att ärva från.

Jag brukar tänka att varje test har en kostnad och ett värde. Oftast är kostnaden rimlig i förhållande till värdet, men i vissa fall är det inte så och då brukar jag försöka hitta billigare sätt att uppnå nästan samma värde.

I denna situation skulle det kunna innebära att du testar en metod som tar referrer “och lite annat” som argument, och låter metoden som tar en HttpRequest vara “otestad” (dvs att den inte täcks av ett automatiserat test). Förmodligen så blir den en eller ett par rader kod där det inte är så stor risk för fel, och att testa den manuellt räcker gott.

Min erfarenhet när det gäller mock-objekt är att de bör undvikas i största möjliga mån. När jag först läste om mock-objekt så tilltalades jag verkligen av tillvägagångssättet. Nästa projekt jag deltog i så försökte vi verkligen exploatera mock-objekt, men såhär i efterhand tycker jag att det har varit för mycket bök med dem (alldeles för hög kostnad) och att det hade gått att genomföra i stor utsträckning utan mock-objekt.

Rent generellt så är det viktigt att ha så få beroenden i koden. Detta gäller även för enhetstesterna. Mock-objekt utnyttjar arv och override av metoder i stor utsträckning, vilket faktiskt minskar förändringsbarheten i de objekt som “mockas”. Att driva utvecklingen med mock-objekt så som förespråkarna för tekniken föreslår är verkligen att hämma förändringsbarheten.