Inledning
Tanken är att detta kommer bli första delen utav många. Vi skall gå in på TDD (test driven development) i ett praktiskt exempel. Schack är det som står på menyn. Detta är inget unikt exempel som vi är ensamma om men vi kodar utifrån egna erfarenheter.
Vi skall börja med att modellera ett schackspel och använda oss av TDD-principer för att driva utvecklingen.
Om du inte redan läst En introduktion till Unit testing så passa på och gör det nu.
Planering
En del kanske tror att TDD inte kräver någon planering alls! Det är fel. Börja alltid med en grundlig planering. Använd whiteboard, rita diagram, samla in krav och framförallt diskutera med övriga inblandade.
Nu blir vår planering ganska kortfattad. Vi skall göra ett schackspel. Schack är för oss ett välkänt spel med tydliga regler. Det är inte alltid så att reglerna finns på plats från början.
Det är viktigt att försöka bryta ned problem i mindre delar och skapa logiska gränser. Gör vi över modelleringen om och om igen och försöker definiera moduler, sedan namnutrymmen och till sist klasser så får vi förhoppningsvis en bra grunddesign. Vi kan sedan börja skriva våra tester!
Vi vill skriva tester som beskriver ett meningsfullt beteende. Tänker du redan nu på 2-dimensionella lagringsstrukturer?
Försök låta bli att tänka på implementationsdetaljer. Du vill INTE tänka på array'er och kodrepresentation för tidigt. Du vill tänka på schack och hur man spelar det! Implementationsdetaljer är ointressanta. Designar vi "rätt" så ska vi t.ex. kunna byta en underliggande lagringsklass utan att våra tester påverkas alls!
Design
Tänk mer på "schackbräde" och "schackpjäser". Dessa kommer att ha beteenden som vi kan skriva tester för. Vi kan nog tänka oss att brädet kommer att ha 8 x 8 rutor. Brädet kommer nog att ha metoder som placerar och flyttar pjäser.
Vad med "schackpjäs"? Skulle det kanske kunna vara en basklass. Alla pjäser skal ju kunna röra sig på ett 2D schackbräde. Det som skiljer dem åt är hur de kan röra sig. Det är kanske lite tidigt att placera in ett arv om vi skall följa TDD.
Kanske ska pjäsen ha en metod som IsLegalMove(board, location)? I så fall så känner brädet till pjäserna och pjäsen känner till brädet. Inte så bra! Blir de kopplade för tätt till varandra så kan vi lika gärna göra en enda klass av alltihop. Gör vi det så kommer testning och modellering att bli mycket svårare!
För att komma runt problemet med för nära kopplingar så får vi bestämma oss för att beroenden bara får ske i "en riktning". Om klass A känner till klass B så söker vi en design där klass B inte känner till klass A. Till huvudfrågan; ska pjäsen känna till brädet eller tvärt om?
Eftersom brädet är en samling av pjäser så borde brädet ha ett beroende till pjäs. Då siktar vi in oss på att pjäserna inte känner till brädet. Jämför detta med en lista med int. Inte skall heltalen behöva känna till listan de ligger i?
Nu kan man hävda att vi borde modellera efter den verkliga världen. Är det inte så att en schackpjäs rör vid brädet? Borde inte pjäsen kunna känna till brädet? Hur skall den annars kunna veta om den flyttas utanför brädet eller om det står en annan pjäs i vägen?
I verkligheten är det så att någon spelar schack. Någon plockar upp en pjäs och placerar den. Överlåter vi detta till användaren så finns det inga regler. Vi måste antagligen införa en "övervakare" som endast erbjuder användaren de giltiga dragen.
Namngivning
Vi gillar att skriva på svenska. Det är en grundidé bakom csharpskolan. Trots detta så föredrar vi att koden skrivs på engelska. I grundläggande artiklar skriver vi alltid på svenska men i mer avancerade ämnen (som detta kan anses) så föredrar vi engelska. Därför går vi nu igenom en liten ordlista så att det blir lättare att följa med i videon.
| Engelska | Svenska |
| chess | schack |
| board | bräde |
| piece | pjäs |
| pawn | bonde |
| rook | torn |
| knight | springare |
| bishop | löpare |
| queen | drottning |
| king | kung |
Dags att börja
Videon är inspelad med Visual Studio Express 2013 - Windows Desktop utan några plugins. Detta så att alla kan följa med utan att behöva köpa t.ex. ReSharper eller liknande. Musik av Muliperi (remix64) har lagts till.
Kodningen sker i realtid.
Test-struktur
Du kanske såg att vi använde nästlade klasser i testerna? Det är inte ofta man använder nästlade klasser men i testfall så blir det en bra indelning med klass->klass som skall testas, nästlad klass->metod som skall testas och metod->specifikt test på metoden.
Phil Haack kanske inte var först med idén men han beskriver den i bättre detalj.