Hvad er Tight Loose Tight ledelse?Liz Guthridge skrev (2018) først om Tight Loose Tight i en artikel på Forbes.com How to drive success with three little words. Her introducerede hun til Tight Loose Tight som ledelsesform. Formen kan kort opsummeres i nedenstående...
Test Driven Development – TDD
Skriv testen før du udvikler eller “Test først udvikling”
Test Driven Development er en softwareudviklingsmetode som bygger på repetition af korte iterative udviklingscyckler. Krav er indbygget i meget specifikke test cases og software udvikles og forbedres til at blive godkendt i testen. Dette er i modsætning til traditionel softwareudvikling der tillader funktionalitet at blive adderet som ikke er bevist at opfylde behovene.
Test Driven Development er relateret til Extreme Programming (XP) som bygger på test først programmering men i den senere tid er der flere som taler for at konceptet skal stå på egne ben som en selvstændig udviklingsmetode.
1. Skriv en test
Dette validerer at testopsætningen fungerer korrekt og første gang vil testen naturligvis fejle da der ikke er lavet kode.
Hvis testen mod forventninger komme ud med en besked om den er lykkes skal test opsætningen gennemses.
2. Kør alle tests og se om den nye test fejler
I Test Driven Development starter hver ny feature med at der skrives en test. Skriv en test der definerer en funktion eller forbedringer til en funktion. Testen bør være meget kortfattet. For at kunne skrive en test må udvikleren være god til at forstå featurens specifikation og behov.
Dette kan opnås gennem udarbejdelse af Use Cases eller User Stories som dækker behov samt undtagelsesbetingelser.
Der er en vigtig forskel ved anvendelse af Test Driven Development i forhold til at skrive testen efter koden er udviklet. Det forhold at udvikleren skal skrive testen før koden medfører at der fokuseres på behov og krav før koden skrives.
3. Skriv koden
Det næste trin er at skrive noget kode som medfører at testen lykkes. Den nye kode er ikke nødvendigvis på dette trin perfekt og vil muligvis lykkes med testen på en mindre elegant måde. Dette er acceptabelt da koden vil blive optimeret i trin 5.
På dette tidspunkt er formålet med den skrevne kode at lykkes med testen. Udvikleren skal ikke skrive kode til funktionalitet som ikke er omfattet af testen.
4. Kør test
Hvis alle test cases lykkes er koden i overensstemmelse med test specifikationer og ødelægger ikke nogle af de eksisterende features. Hvis dette sker skal koden justeres indtil alle test lykkes.
5. Refactorering af koden
Den voksende mængde af kode skal optimeres kontinuerligt under Test Driven Development. Ny kode kan flyttes fra hvor den passede til at lykkes med testen til hvor den mere naturligt hører til.
Identisk kode fjernes. Object, class, module, variabler og metode navne skal fremdarettet understøtte deres formål da nye features og funktioner skal adderes.
Gentag cyklus
Når der startes med en ny test gentages udviklingscyklussen for at addere ny funktioner. Størrelsen på trinene bør altid være små og være 1 til 10 redigeringer mellem hver test kørsel. Hvis ny kode ikke hurtigt tilfredsstiller testen bør udvikleren ”undo” eller på anvende vis gå tilbage til den tidligere kode således kan langvarig debugging undgås.
Test Driven Development
Test driven development er en agil metode til udvikling. Test driven development kan med fordele anvedes sammen med design sprint. Test driven development kan implementeres nemt men kræver test værktøjer. Test driven development medføre ofte udfordringer for udviklere. Test driven development kan tvinge udviklerne til at forholde sig til behovene.Test driven development er en overset agil metode
Indled en dialog
Få mere information om hvordan vi kan udvikle dig, dit team eller din organisation.