Hvad er enhedstestning?
Enhedstest er et selvforklarende ord, hvis man forstår, hvad der menes med enhed. En enhed er det mindste mulige stykke kode, der logisk kan isoleres fra systemet. Dette betyder, at ethvert stykke kode, der kan tage input, udføre en opgave og generere output, selv når det er uafhængigt af hele systemet eller løsningen, kan betegnes som en enhed. Test af dette stykke kode for at generere forventet output på et givet sæt indgange kaldes Enhedstestning.
Typer af enhedsprøvning
Lad os diskutere nogle af typerne af enhedsprøvning.
1) Manuel test
Manuel test af kode kræver, at udvikleren manuelt fejler hver linje i koden og tester den for nøjagtighed. Det kan kræve et trin for trin-instruktionssæt også, hvis funktionaliteten er kompleks.
2) Automatiseret test
Ved automatiseringstest skriver udvikleren kode til testkode. Dette understøttes generelt gennem enhedstestrammer, som ikke er implementeret i produktionen. Andre gange kan en udvikler vælge at skrive testkode uden rammerne og manuelt kommentere den før installationen.
Manuel testning synes åbenlyst tidskrævende i de fleste tilfælde. Men for nogle tilfælde, når man skriver automatiserede testsager, der dækker hvert enkelt scenarie, ikke er muligt, er manuel ofte den foretrukne metode.
Hvorfor er enhedstest vigtig?
For at forstå vigtigheden af enhedstest, er vi nødt til at se på det bredere billede. Det er en del af softwareudviklingen livscyklus. Lad os kort se de andre dele for at få en bedre forståelse af enhedstestens rolle.
Ovenstående billede er en enkel illustration af en normal softwareudviklingslivscyklus og de testprocesser, der er involveret i den. Afhængigt af projektets struktur varierer det unødvendigt hele processen med tilføjelse og fjernelse af visse komponenter. Testprocessen involverer dog helt sikkert fire typer som beskrevet nedenfor:
- Enhedstestning - Det grundlæggende niveau for hele testprocessen. Dette udføres af udvikleren af komponenten eller en af hans kammerater. I sidstnævnte tilfælde betegnes det ofte som peer-test i softwareverdenen.
- Integration Testing - Test af enhedskomponenten med dets umiddelbare overordnede modul. Målet er at kontrollere, om enhedskomponenten integreres godt med de andre komponenter og ikke har forårsaget funktionsfejl i andre komponenter.
- Systemtest - Test hele systemet, når enhedskomponenten er placeret på sin position.
- Test af accept - Normalt udført af virksomheder / klienter, kontrollerer det, om udfaldet er i overensstemmelse med den funktionalitet, som slutbrugeren forventer.
Således kan man meget vel se, at alle testprocesser er afhængige af det grundlæggende testniveau. Hvis det elementære testniveau ikke udføres, kan alle andre testinger resultere i nytteløs.
Lad os nu sige, at du har en kode, der har to dele
- Beregn sammensatte renter.
- Tilføj renterne til hovedbeløbet, og beregne modenhedsydelsen.
Lad os antage, at du ikke testede enheder nogen af disse komponenter og fortsatte direkte til systemtest. En fejl opstår ved systemtest, at modenhedsværdien er forkert. Hvilken del af koden har nu en fejl?
- Det kan være i beregningen af renter.
- Det kan være ved anvendelse af den sammensatte logik.
- Det kan tilføje renter til hovedbeløbet.
Se, hvordan det øger indsatsen nu. Alt dette kunne have været undgået, hvis begge kodekomponenter var blevet testet enhed.
Hvorfor er enhedstest vigtig?
- Det løser kun bugs tidligt i udviklingsstadiet. Dette sparer meget tid, kræfter og omkostninger. Forestil dig, at hvis der ikke blev udført enhedstest, ville koden gå til og fra kvalitetssikringsteamet for meget enkle problemer.
- Gode enhedsprøver tjener også formålet med detaljeret dokumentation. Når en udvikler skriver enhedstestsager, skriver han utilsigtet den forventede funktionalitet af koden. Dette er simpelthen intet andet end dokumentation, der forklarer funktionen af koden.
- Det gør det let at ændre og vedligeholde kode. Når du har foretaget ændringer i koden, skal du køre testerne igen og viola, alle fejlene bliver fanget uden problemer.
- Det håndhæver også modularitet. Enhedstest køres på individuelle komponenter, hvilket betyder, at koden skal være så kornet som muligt. Dette sikrer, at koden passende opdeles i moduler.
Den anden side af mønten
Det har også nogle ulemper. Selvom fordelene vejer over ulemperne, og det anbefales altid at enhedstest din kode, er det alligevel også fornuftigt at kende begge ansigter på den samme mønt.
- Enhedstestning, hvordan-så-nogensinde grundig, kan undertiden ikke kunne fange alle fejlene i den mest trivielle kode også. Det er simpelthen ikke muligt at evaluere alle udførelsesstier. Således er enhedstest ofte ligetil happy-path og negative scenarier.
- Det kræver, at en udvikler tænker ud af boksen og prøver at bryde hans kode. Dette er ofte vanskeligt, da opfattelsen af en udvikler bliver partisk mod koden.
Enhedstestværktøjer
Der er adskillige værktøjer i branchen til at hjælpe med automatiserede enhedsforsøgssager. Som det er formålet, gør de skrivning og eksekvering af enhedstestsager lettere for udvikleren. Der er en verden af enhedsprøvningsrammer ved udbetaling af udviklere. Nogle af de mest populære og mest anvendte værktøjer er vist nedenfor.
JUnit
JUnit er et gratis værktøj til brug af test til Java. Det er automatisk inkluderet i mange projektskabeloner, der er tilgængelige med forskellige IDE'er til Java-udvikling. Det, der gør JUnit speciel, er, at den tester dataene først og derefter tester koden, efter at dataene er indsat i dem. Det giver også påstande om at identificere testmetoderne.
NUnit
NUnit er til. Net som JUnit er til Java. Det har alle de fremtrædende træk ved JUnit, men til udvikling i .Net-programmeringssprog. Det understøtter også kørsel af testene parallelt.
PHPUnit
I lighed med JUnit og NUnit er PHPUnit et værktøj til PHP-udviklere. Det understøtter også alle elementære funktioner i et godt testværktøj.
xUnit
En anden ramme, der er mere generisk end dens modparter, er XUnit. Det understøtter flere sprog som C ++, C #, ASP.Net osv. Det kan også prale af lignende funktioner som andre værktøjer, der findes på markedet.
Jtest
Parasoft Jtest er et tredjeparts plugin, der udnytter open source-rammer som JUnit og tilføjer løsninger med et enkelt klik for at gøre livet lettere. Med Jtest kan du automatisk generere testkoder til din kode med bare et par klik. Ved at automatisere disse opgaver er det fri for udvikleren at arbejde på forretningslogikken for testsagerne.
QUnit
En meget populær ramme for test af JavaScript-enhed. Det kan teste JavaScript-kode både på klientsiden og serversiden.
Jasmine
Et andet meget brugt testværktøj til JavaScript-rammer. Det har stor samfundsstøtte til Angular, React osv.
JMockIt
JMockIt er et open source-værktøj, der også understøtter hån til API-opkald med optagelses- og verificeringssyntaks.
Eksempel på enhedstest
Et meget grundlæggende krav i enhver enhedstesttilstand er koden, der skal testes. Lad os antage, at vi har en funktion, der validerer, om telefonnumrene er korrekte (i form af format) eller ej. Afhængigt af den geografiske placering kan dette kriterium også variere. Så vi vil ikke understrege kriterierne. Vi vil snarere fokusere på enhedens testtilfælde.
public class PhoneValidator
(
public bool IsPhoneValid(string phone)
(
/* write some code to verify if the phone is valid or not. return true, if the phone is valid. return false, if invalid. */
)
)
Nu skal vi teste dette stykke kode.
Vi kan enten teste det manuelt ved at indsætte forskellige værdier og verificere output. Dette kan synes let ved det første blik, men vil være en gentagen opgave, hvis der foretages ændringer i koden.
Alternativt kan vi skrive en enhedstest, der kan fungere som min validator, så længe forretningslogikken forbliver den samme. Enhedens testtilstand ændres ikke, selvom vi ændrer koden. Så lad os skrive en enhedstesttilstand til ovenstående kode.
public void TestPhoneValidator()
(
string validPhone = "(123) 456-7890";
string invalidPhone = "123 45"
PhoneValidator validator = new PhoneValidator();
Assert.IsTrue(validator.IsPhoneValid(valid phone));
Assert.IsFalse(validator.IsPhoneValid(invalidPhone));
)
Så hvordan fungerer ovenstående enhedstestkode? Bemærk de to Assert-udsagn. De sørger for, at testen kun passerer, hvis de to linjer modtager sand og falsk fra de respektive IsPhoneValid-funktionskald.
Du vil spørge, hvad er fordelene ved at skrive denne test sag? Hvis du har tusinder af telefonnumre til at validere i et ægte scenarie, behøver du ikke manuelt at verificere hver gang debuggeren rammer koden. Du skal blot ringe til testkoden tusinder af gange, så fortæller du, hvilke test der er bestået, og hvilke der mislykkedes. Nu skal du kun inspicere de mislykkede.
Tip til enhedstest
- Brug altid et værktøj eller ramme, der understøtter dit sprog. Værktøjer gør det nemt at udvikle enhedstesttilfælde. Du kan ende med at lægge ekstra anstrengelser ellers.
- Selvom det anbefales til alt, er det undertiden praktisk at springe over koder, der er enkle og ikke påvirker systemets opførsel direkte. For eksempel kan getter- og setterkoder være mindre fokuseret på.
- Spring aldrig over koder, der direkte påvirker systemet eller er afgørende for implementeringen af forretningslogikken.
- Brug testdata, der ligner produktionsdata.
- Isoler din kode. Hvis din kode er afhængig af data fra databasen, skal du ikke skrive en testsag for at ringe til databasen og få værdier. Opret i stedet en grænseflade og hån med API og databasekald.
- Før du løser en fejl, der opstår som enhedstest, skal du skrive den testtilfælde, der afslører manglen. Der er tre grunde til at gøre det:
- Du vil være i stand til at fange regressionsfejl, der opstår som følge af din løsning.
- Din test sag er nu mere omfattende.
- Ofte er en udvikler for doven til at opdatere sine testsager, når den først er skrevet.
- Ud over at skrive testtilfælde, der bekræfter forretningslogikken, skal du skrive sager, der også tester udførelsen af din kode. Især når koder involverer looping, er ydelsen det mest påvirkede område.
Ting at huske
- Enhedstestsager skal være uafhængige af
- Koden, der skal testes - Enhver ændring i koden skal ikke kræve ændring i enhedstesttilstand, medmindre virksomhedslogikken i sig selv ændres. For eksempel, hvis logikken nu kræver, at et gyldigt telefonnummer altid skal starte med '+', skal enhedens testtilstand ændres, ellers ikke.
- Den anden kode - Der skal ikke være nogen interaktion eller afhængighed med noget andet stykke kode eller databaseværdi eller noget sådant. En enhed skal isoleres, når den testes.
- Følg klare og konsistente navnekonventioner for dine testtilfælde. Det gør det lettere at spore scenarierne. Du kan også bruge versionskontrolværktøjer til at holde styr på dine testsager.
- Overfør aldrig din kode til den næste fase, før den er udført, fejl er rettet og testet igen.
- Vigtigst af alt, gør det til en vane. Dette er en kodningspraksis, der skal inkuleres. Jo mere du koder uden enhedsprøvning, desto mere fejlagtigt er din kode.
Karriere inden for enhedstest
Selvom enhedsafprøvning ikke er noget felt som helhed, er det alligevel en ekstra pil i din quiver. Det er en god kodningspraksis, og hvornår foretrækkes ikke gode kodere?
Konklusion
Det kan ubestridt konkluderes, at enhedstestning kan være enkel undertiden og kompleks andre tidspunkter. Det er når værktøjer og rammer kommer til din redning. Selv med test af enheden er koden ikke helt korrekt bevis. Det er når testprocedurerne på næste niveau sparker i gang. Blandt alle disse usikkerheder er det eneste, der er sikkert, at enhedsprøvning er nødvendig.
Anbefalede artikler
Dette har været en guide til enhedstestning. Her diskuterede vi vigtigheden, tip, værktøjer, karriere og typer af enhedsprøvning med dens eksempler. Du kan også gennemgå vores andre foreslåede artikler for at lære mere -
- Test af interviewspørgsmål
- Web-testapplikation
- Defekter livscyklus i softwaretest
- Karrierer inden for softwaretestning
- Liste over testrammer til Java