I dagens högintensiva mjukvaruutvecklingsmiljö Det är vanligt att höra orden Test-Driven Development (TDD). Diskussion om dess fördelar, såväl som nackdelar, är mycket vanliga i mjukvaruutvecklingsgemenskapen.
Vissa säger att TDD är en ”orealistisk ineffektiv moralkampanj för självförakt och skam” och andra att det är ”bara ett verktyg som hjälper oss att designa snabbare med hjälp av refactoring” [2].
”Dåliga programmerare har alla svaren. Bra testare har alla frågor.
— Gil Zilberfeld
Men testdriven utveckling är inte ett nytt barn i stan.
Den tidigaste allmänt kända referensen kommer från 1957 i D.D. McCrackens ”Digital Computer Programming: The First General Introduction in Book Form, Stressing Actual Work with Computers”. Även om TDD inte antogs allmänt under de få åren som följde, IBM körde ett projekt för NASA på 1960-talet där utvecklare ”skrev tidiga enhetstester till mikrosteg.
Under en varm sommarkväll 1989 utvecklades Kent Beck det första kända TDD-ramverket - SUNit - och provade det på Smalltalk. TDD föddes sedan eller, mer exakt, återupptäcktes. Strax efter började Agile- och TDD-rörelser uppmuntra programmerare att skriva automatiserade enhetstester och därmed lägga till testning till utvecklingsdisciplinen.
Till en början, som med många nya saker, verkade det bara ”lägga till tid till dagjobbet”. De flesta av oss förstod inte riktigt fördelarna med att följa sådana metoder, var skeptiska och kritiska till TDD, eftersom det sågs som ganska onödig tid och ansträngning.
Men innan vi går vidare, låt oss gå tillbaka och överväga: Vad är testdriven utveckling?
I ett nötskal, TDD är handlingen att skriva ett automatiserat test innan du skriver en funktion.
Som ett exempel, låt oss säga att Bob behöver utveckla en ny funktion för sin fantastiska nya sociala nätverksidé. Bob börjar med att skriva ett automatiserat test och medan funktionen inte implementeras korrekt kommer testet att misslyckas (dvs. rött ljus). Så Bob skriver minsta mängd kod för att få testet att passera (dvs. grönt ljus).
Sedan, när han har grönt ljus, rensar Bob upp koden och ser till att funktionen fortfarande implementeras korrekt genom att köra testerna (dvs. han omfaktoriserar koden). Utan dubbleringar är koden och automatiserade tester lätta för andra att underhålla.
Denna procedur är också känd som ”röd/grön/refaktor mantra”, där rött betyder misslyckade tester och grönt betyder godkänt prov. Robert Cecil Martin, en av ledarna för den smidiga metodrörelsen (och bekant för många som farbror Bob), nämnde i ”Clean Code” att skriva tester innan man skriver produktionskod bara är toppen av isberget.
”Det enda sättet att göra tidsfristen - det enda sättet att gå snabbt - är att hålla koden så ren som möjligt hela tiden.”
— Farbror Bob, Ren kod
För att lyfta fram de verkliga fördelarna med TDD gör vi en övning.
Låt oss föreställa oss att vi ska starta en ny mjukvara utan testdriven utveckling. Vi implementerar en app för användare att hantera sin blogg.
Låt oss börja med att implementera vår första funktion: tillåta användare att registrera sig för att skapa sin blogg. När koden är klar måste vi testa den manuellt för att se om allt fungerar smidigt.
När vi är nöjda med den första funktionen kan vi börja koda funktion nummer två: tillåta användare att lägga till blogginlägg. Och när den koden är klar testar vi den andra funktionen manuellt för att se om den fungerar korrekt. När vi är nöjda kan vi gå vidare till nästa funktion, eller hur?
Men... hur vet vi att den nya koden inte bröt användarregistreringsprocessen (första funktionen)?
Vi kan testa den första funktionen manuellt och se om den fortfarande fungerar. Betyder detta att varje gång vi lägger till en ny funktion måste vi manuellt utföra N+1-tester?
Svaret är ja.
Resultatet är att det är så otroligt dyrt att manuellt testa alla funktioner när en ny utgåva görs, att projekt utan TDD är mycket benägna att regressera. När det gäller mjukvaruutveckling sker en regression när en funktion som fungerade i en tidigare version verkar vara trasig i en senare version.
Slutsatsen är att projekt där TDD tillämpas oftast har färre buggar än projekt utan automatiserade tester. Men automatiserade tester är inte gratis.
Att utveckla en funktion med automatiserade tester kan kosta 20% till 50% mer än utan tester. Men när programvarans komplexitet växer blir det allt svårare att manuellt testa varje enskild funktion.
Efter implementeringen av några funktioner lönar sig det redan att investera tid i att skriva automatiserade tester.
I mjukvaruutvecklingsgemenskapen är det nu allmänt accepterat att projekt med automatiserade tester är mindre buggiga än projekt utan automatiserade tester.
Det är också allmänt accepterat att omkostnaderna för att skriva ett test lönar sig genom att förhindra buggar från att träffa produktionsmiljön. Färre buggar betyder en bättre produkt. Och det översätts vanligtvis till lyckligare användare. För att inte tala om lyckligare utvecklare, som kan spendera sin tid på att göra en bättre produkt, istället för att ständigt fixa buggar.
Men hur mycket testning är tillräckligt? Behöver vi skriva automatiska tester för varje enskild funktion?
Svaret är: det beror på.
I TDD finns det ingen formell testplan, vilket gör det till en informell process. Därför är andelen kod som behöver testas en enorm debatt.
”Hur man testar?” är en fråga som inte kan besvaras generellt. ”När ska man testa?” har dock ett allmänt svar: så tidigt och så ofta som möjligt.”
— Björne Strøstrup, Programmeringsspråket C++
Vi observerade att att få testtäckningen till över 80% inte ger större fördelar. Vi hade så få buggar som inträffade när vi tillämpade 80% -regeln, att skriva ännu fler tester hade mycket, mycket marginella fördelar.
För att sätta det i den verkliga världen, låt oss bara ta ett exempel.
Nyligen på ett projekt för en omfattande plattform, på grund av viss press på deadlines för ett par sprints, tvingades vi minska den automatiska testtäckningen till 60% av koden.
När nya funktioner släpptes med lägre täckning började vi få fler regressioner. Efter att ha slutfört två sprintar med 60% kodtäckning bestämde vi oss för att använda en hel sprint bara för att fixa buggar och sätta testtäckningen tillbaka på rätt spår.
Hade vi inte haft en nedgång i täckningen skulle vi bara bli försenade med en halv sprint, istället för en full sprint. Så det är en hel vecka som vi kunde ha sparat bara genom att öka vår testtäckning i första hand.
Föreställ dig hur någon känner när tiden ägnas åt att bara sopa upp efter dig själv, inte bygga större och bättre saker.
Vår tumregel är att alltid tillämpa automatiserade tester för de mest komplexa funktionerna. Vi utvecklar bara automatiserade tester för enkla funktioner om täckningen utan dessa är under 80%. Detta innebär att vi lägger mindre tid på att fixa buggar och färre problem tas upp av slutanvändare.
Så, för att sammanfatta, på Imaginärt moln Vi älskar TDD och 80% kodtäckning är vårt magiska nummer.
Ju mer komplex funktionen är, desto högre är den på vår testprioritetslista.
Vi har ett team av experter på mjukvaruutveckling på Imaginärt moln. Om du tror att du kan behöva lite hjälp med ditt digitala projekt, skicka oss en rad här!
Hittade den här artikeln användbar? Du kanske gillar dessa också!
VD @ Imaginary Cloud och medförfattare till boken Product Design Process. Jag gillar mat, vin och Krav Maga (inte nödvändigtvis i denna ordning).
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
