Need-Driven D evelopment

… and software development ;-)

Need-Driven DevelopmentIT-forretningsudviklings softwareudviklingsprincipper


Mål

• Kvalitet

• Vedligeholdbarhed

• Frygtløs udvikling ;-)


PrincipperNeed-Driven Development (NDD)

=Acceptance Test-Driven Development (ATTD)

(aka Storytest-Driven Development)

+mockist Test-Driven Development (mTDD)


Arbejdsgang


Trin 1: Accepttest/kravanalyse (ATDD)• Skriv kendte stories/scenarier (på kundens/brugerens

domænesprog) med kode i et afventende (en. pending) tilstand, når de dukker op.

• Hvis programmet har et brugergrænseflade, er der også en god idé at fange brugernes ønsker ved at bruge GUI-prototyper.

• Laves fortrinsvis som integrationstests, men kan dog laves med fakes (fx. SQLite istedet for Oracle) hvis det bliver for komplekst.

• Påbegynde en gennemførelse af et scenarie (aka. feature) ved at ændre tilstand af et scenario til fejlende (en. failing).


Trin 1: Accepttest-/kravanalyseeksempel


Trin 1: Accepttest-/kravanalyseeksempelKode

VS output XML-rapport


Trin 1: Accepttest/kravanalyse (ATDD)I forrige slide blev StoryQ brugt som ATDD-værktøj. StoryQ har mange gode ydelser, men man skal være meget bevist om at eksekverbare krav skal tilpasses kunden/domæne-eksperten/brugeren.

Hvis denne fx. er god til at definere krav som eksempler i Excel, så skal naturligvis han/hun gøre det. Man skriver simpelthen en lille smule kode som benytter Excel-ark som accepttestinput.

Konklusion: Hvert projekt analyserer hvordan man gør kravene eksekverbare, sådan at domæneeksperten ikke unødvendigt generes.


Trin 2: DesignanalyseLav en grov udformning af klasser og deres samarbejde og afhængigheder.

Gør dette sammen med en eller flere kolleger, eller i det mindste gennemgå det sammen med en, før implementering.


Trin 2: Designanalyseeksempel


Trin 3: Enhedstester (mTDD)Starte outside-in, dvs. starte med klassen tættest på overfladen af systemet og bor ned én klasse ad gangen, og implementere klasserne med teste først-stil sådan:

• Skriv en assertion (mod ikke-eksisterende kode ≡ debit) og skriv/generere lige nok kode så at det kompilerer• Hvis klassen er en service eller lignende, injicere afhængigheder som mock-instanser af interfaces med forventninger i

konstruktøren

• Hvis klassen er en del af en domænemodel, og mapped til databasen med NHibernate, benyt properties til samarbejdspartnere

• Kør testen og se den mislykkes (rødt lys)

• Skriv den mindste mængde af kode muligt, for at bestå testen (≡ kredit)

• Kør testen og se den blive godkend (grønt lys)

• Refaktorere koden efter behov (dvs. sørg for at koden er clean (Bemærk! Refaktorere aldrig mens i mislykket/rødt tilstand!)

• Genkør testerne efter hver kodeændring, uanset hvor lille

Gentag ovenstående trin, indtil de trin som er afhængige af denne klasse i aktuelt scenario bestås, og påbegynd den næste klasse i rækken for at opfylde det fejlende scenario. Dine erfaringer med mockserne fra den foregående test fortæller (opsatte forventninger), hvad der er behov for.


Trin 3: Enhedstesteksempel


Trin 4: AccepttestimplementeringFå scenariet/accepttesten at blive godkend ved at integrere de klasser som har blevet udviklet i trin 3.

Integrere er typisk set tilføjelse af interface/konkret klasse-par i dependency injection (DI)-rammeværket.


Trin 4: DI-eksempel


Mål - revurderede• Kvalitet • Krav som eksekverer plus debit og kredit for klasserne

• Vedligeholdbarhed • Små klasser, små metoder, eksplicitte roller (interfaces), krav som kode, rigtig høj

testdækning , …

• Frygtløs udvikling• Jeg koder uden frygt i et projekt hvor man kan læse kravene ved at eksekvere dem, finde

en enhedstestsuite (debit) som afspejler produktionskoden (kredit), der hver type og

metode kun gør en ting og dækningsanalysen giver et resultat tæt på 100%.


Hjælp• Clean Code-bog

• Eksempelprojekt (Desktop CRU)

• Skabelonprojekt

• Uddannelseforløb

• MRL ;-)

Need-Driven D evelopment

Documents

Transcript of Need-Driven D evelopment