En härlig sak med mocking är att det samtidigt som jag får sköna unittests (utan integrationsstuff...) alltid får mig att snäppa upp min design. Mocking frameworks som NMock är bra men det går alldeles utmärkt att lämna dessa på hyllan och göra det hela själv... Och även om ni använder dem så måste ni ändå lura ut hur ni skall trixa in mockobjektet... Det viktigaste är ändå designen och det är oftast tre designval att välja mellan för att trycka in vårt fuskobjekt.... (Ingen hjärnkirurgi...)

- Dependency injection (Släng in mockobjektet i aktuell konstruktor)

public class Idol2007VotingService
{
private IVotingService remoteVotingService;
public Idol2007VotingService(IVotingService votingService)
{
remoteVotingService = votingService;
}
}

Det kassa med detta är att det bryter inkapslingen. Kan man leva med detta? Oftast... Om inte...

- Använd ett factoryobjekt

public class Idol2007VotingService
{
private IVotingService remoteVotingService;
public Idol2007VotingService()
{
remoteVotingService = ServiceFactory.CreateRemoteVotingService();
}
}

public class ServiceFactory
{
private static bool shouldCreateRemoteService = false;
public static IVotingService CreateRemoteVotingService()
{
if(shouldCreateRemoteService == true)
{
return new RemoteService();
}
else
{
return new MockService();
}
}
}

Det kassa med detta är att vi får ett dependency till test från vår produktionskod (mockobjektet). Kan vi leva med det? Om inte...

- Endo testing (subklasser kontrollerar dependency)

public class Idol2007VotingService
{
private IVotingService remoteVotingService;
public Idol2007VotingService()
{
remoteVotingService = createRemoteVotingService();
}

protected virtual IVotingService createRemoteVotingService()
{
return new RemoteVotingService();
}
}

Nu får vi det västa från alla världar... Cool! Subklasser är ansvariga för att skapa det aktuella objektet vilket gör att testklassen bara väljer vilken klass den skall skapa (Mocken) medan produktionskoden kör med basklassen (det riktiga objeketet)

Fördelar med endo testing:
- All testkod är inkapslad i subklasser (inte del av produktionskod)
- Snygg och klar gräns mellan test och produktionskod
- Klassen gör det den ska och vet inte om någonting om test

Micke erkänner:
När jag läste GOF på Universitetet kände jag mig ofta helt korkad. Jag kunde läsa ett stycke sådär en 10-15 gånger, förstå alla enskilda ord, men samtidigt inte ha en aning om vad det stycke jag just läst egentligen betydde. Jag såg mig själv lämna programmeringsbranschen för att istället satsa på grönsaksdisken på Matpiraten ända tills jag upptäckte "Head First Design Patterns". Helt plötsligt förstod jag! Att man kunde göra något så enkelt... Så svårt... GOF, ni var nära att få mig att sortera morötter... Men ni lyckades inte! Sweet!