Need-Driven D evelopment

1. Need-DrivenDevelopment IT-forretningsudviklings softwareudviklingsprincipper

2. Mål • Kvalitet • Vedligeholdbarhed • Frygtløs udvikling ;-)

3. Principper • Need-DrivenDevelopment (NDD) • = • AcceptanceTest-DrivenDevelopment (ATTD) • (akaStorytest-DrivenDevelopment) • + • mockistTest-DrivenDevelopment (mTDD)

4. Arbejdsgang

5. 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. SQLiteistedet 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).

6. Trin 1: Accepttest-/kravanalyseeksempel

7. Trin 1: Accepttest-/kravanalyseeksempel Kode VS output XML-rapport

8. 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.

9. Trin 2: Designanalyse Lav 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.

10. Trin 2: Designanalyseeksempel

11. 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-stilså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-instanseraf 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) • Refaktorerekoden efter behov (dvs. sørg for at koden er clean (Bemærk! Refaktorerealdrig mens i mislykket/rødt tilstand!) • Genkørtesterne efter hver kodeændring, uanset hvor lilleGentag 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 mocksernefra den foregående test fortæller (opsatte forventninger), hvad der er behov for.

12. Trin 3: Enhedstesteksempel

13. Trin 4: Accepttestimplementering Få 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 dependencyinjection (DI)-rammeværket.

14. Trin 4: DI-eksempel

15. 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%.

16. Hjælp • CleanCode-bog • Eksempelprojekt (Desktop CRU) • Skabelonprojekt • Uddannelseforløb • MRL ;-)