Dette er et utdrag fra Unit Testing Succinctly eBook, av Marc Clifton, gitt vennlig av Syncfusion.
Den vanlige mantraen vi hører om hvilken som helst programvare metodikk er at den forbedrer brukervennlighet og kvalitet, reduserer utvikling og testingstid, og bringer produktet til markedet raskere og med færre feil. Dette er høye mål, men jeg har ennå ikke sett en metodikk som leverer grensen til programvareutvikling.
Til slutt er den primære grunnen til å skrive enhetstester å bevise korrekthet, og dette skjer bare hvis du skriver enhetsprøver vi vil. Enhetstester av seg selv vil ikke direkte forbedre brukbarheten eller kvaliteten på produktet ditt. Du kan fortsatt gjøre et rot i applikasjonen om det er bevist riktig eller ikke, og det er absolutt ikke garantert å redusere utviklings- og testtid (mer om dette senere) eller bringe produktet på markedet før.
Så, la oss være klare og virkelige fra get-go: Enhetstesting kan brukes til å verifisere korrekthet og eventuelle bivirkning Det som skjer med hensyn til utviklingsprosessen må balanseres med innsats for å skrive og vedlikeholde nyttige enhetstester.
Velskrevne enhetstester vil gi deg en målbar grad av selvtillit at det mangfold av metoder som omfatter din søknad vil oppføre deg riktig. Den enkleste måten å objektivt gjøre denne målingen er en dekningstest: Hvilken prosentandel av metodene i søknaden din har enhetstester skrevet mot dem? Selv om dette spørsmålet ikke direkte tar opp om en metode skal betraktes som en enhet (diskutert senere), eller om testene er meningsfulle, er det likevel en måling du kan ta når som helst og kan brukes som referanse for korrektheten av din søknad.
Enhetstesting er en iterativ prosess. Det vil alltid være feil som er savnet med enhetstesting. Imidlertid gir antallet feil som rapporteres over tid, og antall uløste versus løst problemer, meningsfull informasjon om søknadens helse. Selv om det er umulig å si: "Ved testing av enheter har antall bugs blitt redusert med 50 prosent." Det er mulig å måle hvor mange feil søknaden din har på grunn av ufullstendige enhetstestdekning. Når du skriver enhetstester for å bekrefte problemet og reparasjonen, kan du også måle hvor mange enhetstester du har skrevet mot rapporterte feil i forhold til totalt antall enhetstester.
Alle disse referansene gir en grad av objektivitet mot utviklingsprosessen. Derfor er en av fordelene ved enhetstesting at den gir alle, fra utviklere til ledere, objektiv informasjon som kan mates tilbake til utviklingsprosessen for å forbedre prosessen.
En annen fordel er repeterbarhet, ellers kjent som regresjonstesting. Når et søknad modnes, vil vi sørge for at eksisterende, arbeider Koden er ikke ødelagt. Ved å skrive enhetstester mot metoder som de er skrevet og legge til enhetstester for feil som de er rapportert, kan alle disse bli testet automatisk når ny kode er lagt til eller eksisterende kode endres. Enhetstester blir et betydelig tidsreduksjonsverktøy når det gjelder å teste om et program fortsatt fungerer riktig etter en mindre eller betydelig kodeendring. Mens enhetstesting ikke erstatter brukervennlighetstesting, ytelsestesting, belastningstesting og så videre, hjelper det definitivt å eliminere tiden bortkastet på det vanlige spørsmålet: "Dette virket før; hvorfor gjør det ikke nå? "
Det er enkelt å teste at en metode gjør det rette når alle prosessene i metoden utføres lineært. Men når du legger til en hvis
uttalelse eller a bytte om
uttalelse, du oppretter syklomatisk kompleksitet, som er en fancy måte å si at koden din nå har flere utførelsesbaner. De mest nyttige enhetstester er de som tester hver eneste kodenavn som skjer i metoden din. Å skrive slike typer tester kan være omhyggelig, men det er vel verdt innsatsen, da de garanterer at minst hver kodegrense har blitt utført, noe som ikke kan forekomme under aksepttesting, brukervennlighetstesting eller annen testing som kvalitetssikringen avdelingen (hvis du har en) utfører.
Gjennom hele denne serien skal vi se på en rekke forskjellige strategier og tips for hvordan du utfører effektiv enhetstesting.