Hva er enhetstesting?
Enhetstesting er et selvforklarende ord hvis man forstår hva som menes med Enhet. En enhet er det minste koden som kan logisk isoleres fra systemet. Dette betyr at ethvert stykke kode som kan ta innspill, utføre en oppgave og generere output selv når det er uavhengig av hele systemet eller løsningen, kan betegnes som en enhet. Testing av dette kodestykket for å generere forventet output på et gitt sett med innganger kalles Unit Testing.
Typer enhetstesting
La oss diskutere noen av typene enhetstesting.
1) Manuell testing
Manuell testing av kode krever at utvikleren manuelt feilsøker hver linje i koden og tester den for nøyaktighet. Det kan kreve et trinnvis instruksjonssett også hvis funksjonaliteten er kompleks.
2) Automatisert testing
I automatiseringstesting skriver utvikleren kode til testkode. Dette hjelper generelt gjennom Unit Test-rammer som ikke er distribuert i produksjon. Andre ganger kan en utvikler velge å skrive testkode uten rammeverk og manuelt kommentere den før distribusjon.
Manuell testing virker åpenbart tidkrevende i de fleste tilfeller. Men for noen tilfeller når man skriver automatiserte testsaker for å dekke hvert enkelt scenario ikke er mulig, er manuell ofte den foretrukne metoden.
Hvorfor er enhetstesting viktig?
For å forstå viktigheten av enhetstesting, må vi se på det bredere bildet. Det er en del av programvaren utvikling livssyklus. La oss kort se de andre delene for å få en bedre forståelse av rollen som enhetstesting.
Bildet ovenfor er en enkel illustrasjon av en normal livssyklus for programvareutvikling og testprosessene som er involvert i den. Unødvendig å si, avhengig av prosjektets struktur, varierer hele prosessen med tilsetning og fjerning av visse komponenter. Testprosessen involverer imidlertid helt sikkert fire typer som beskrevet nedenfor:
- Enhetstesting - Elementærnivået i hele testprosessen. Dette utføres av utvikleren av komponenten eller noen av hans jevnaldrende. I sistnevnte tilfelle blir det ofte betegnet som peer testing i programvareverdenen.
- Integrasjonstesting - Testing av enhetskomponenten med den umiddelbare overordnede modulen. Målet er å sjekke om enhetskomponenten er godt integrert med de andre komponentene og ikke har forårsaket funksjonsfeil i noen annen komponent.
- Systemtesting - Test hele systemet når enhetskomponenten er plassert.
- Godkjenningstesting - vanligvis utført av virksomheter / klienter, og kontrollerer om utfallet stemmer overens med funksjonaliteten som sluttbrukeren forventer.
Dermed kan man godt se at alle testprosessene er avhengige av det grunnleggende testnivået. Hvis det grunnleggende testnivået ikke er utført, kan alle andre tester føre til meningsløst.
La oss si at du har en kode som har to deler
- Beregn sammensatte renter.
- Legg renten til hovedbeløpet og beregne forfallsstønaden.
La oss anta at du ikke testet enheter av disse komponentene og gikk videre til systemtesting. En feil oppstår ved systemtesting om at forfallsverdien er feil. Hvilken del av koden har nå en feil?
- Det kan være i beregningen av renter.
- Det kan være å anvende sammensettingslogikken.
- Det kan være i tillegg til renter til hovedbeløpet.
Se hvordan det øker innsatsen nå. Alt dette kunne vært unngått hvis begge kodekomponentene hadde blitt testet enhet.
Hvorfor er enhetstesting viktig?
- Den fikser feil bare i utviklingsstadiet. Dette sparer mye tid, krefter og kostnader. Tenk om det ikke var foretatt enhetstester, ville koden gått til og fra kvalitetssikringsteamet for veldig enkle problemer.
- Gode enhetstester tjener også formålet med detaljert dokumentasjon. Når en utvikler skriver casetester, skriver han utilsiktet den forventede funksjonaliteten til koden. Dette er rett og slett ikke annet enn dokumentasjon som forklarer bruken av koden.
- Det gjør det enkelt å endre og vedlikeholde kode. Når du har gjort noen endringer i koden, kjører testene igjen og bratsj, blir alle feilene fanget uten problemer.
- Det håndhever også modularitet. Enhetstester kjøres på individuelle komponenter, noe som betyr at koden må være så granulær som mulig. Dette sikrer at koden er passende delt inn i moduler.
Den andre siden av mynten
Det har noen ulemper også. Selv om fordelene veier over ulempene, og det alltid anbefales å enhetstest koden din, er det likevel fornuftig å kjenne begge ansiktene til den samme mynten.
- Enhetstesting, hvor som helst grundig, kan noen ganger ikke klare å fange opp alle feilene i den mest trivielle koden også. Det er rett og slett ikke mulig å evaluere alle utførelsesveiene. Dermed er enhetstester ofte greie happy-path og negative scenarier.
- Det krever at en utvikler tenker ut av boksen og prøver å bryte koden hans. Dette er ofte vanskelig ettersom oppfatningen til en utvikler blir partisk mot koden.
Enhetstestverktøy
Det er flere verktøy i bransjen for å hjelpe deg med automatiserte enhetstesttilfeller. Som formålet er, gjør de skriving og utførelse av testtestsaker enklere for utvikleren. Det er en verden av enhetstesting rammer ved utbetaling av utviklere. Noen av de mest populære og mest brukte verktøyene er listet opp nedenfor.
JUnit
JUnit er et gratis å bruke testverktøy for Java. Det er automatisk inkludert i mange prosjektmaler som er tilgjengelige med forskjellige IDE-er for Java-utvikling. Det som gjør JUnit spesiell er at den tester dataene først og deretter tester koden etter at dataene er lagt inn i den. Den gir også påstander for å identifisere testmetodene.
NUnit
NUnit er å .Net som JUnit er til Java. Det har alle de fremtredende egenskapene til JUnit, men for utvikling i .Net programmeringsspråk. Det støtter også å kjøre testene parallelt.
PHPUnit
I likhet med JUnit og NUnit, er PHPUnit et verktøy for PHP-utviklere. Den støtter også alle elementære funksjoner i et godt testverktøy.
xUnit
Et annet rammeverk som er mer generisk enn kollegene, er XUnit. Den støtter flere språk som C ++, C #, ASP.Net, etc. Den har også lignende funksjoner som for andre verktøy som er tilgjengelige i markedet.
Jtest
Parasoft Jtest er en tredjeparts plugin som utnytter open source-rammene som JUnit og legger til ett-klikk-løsninger for å gjøre livet enklere. Med Jtest kan du automatisk generere testkoder for koden din med bare noen få klikk. Ved å automatisere disse oppgavene står utvikleren fritt til å jobbe med virksomhetslogikken til testsakene.
QUnit
Et veldig populært rammeverk for JavaScript-enhetstesting. Den kan teste JavaScript-kode både på klientsiden og serversiden.
Jasmine
Et annet veldig mye brukt testverktøy for JavaScript-rammer. Den har stor samfunnsstøtte for Angular, React, etc.
JMockIt
JMockIt er et åpen kildekodeverktøy som også støtter å spotte API-anrop med innspillings- og verifiseringssyntaks.
Eksempel på enhetstest
Et helt grunnleggende krav i en enhetstesttilstand er koden som skal testes. La oss anta at vi har en funksjon som bekrefter om telefonnumrene er riktige (i form av format) eller ikke. Avhengig av den geografiske plasseringen, kan dette kriteriet også variere. Så vi vil ikke legge vekt på kriteriene. Snarere vil vi fokusere på enhetens testtilfelle.
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. */
)
)
Nå må vi teste dette stykke koden.
Vi kan enten teste det manuelt ved å sette inn forskjellige verdier og verifisere utdataene. Dette kan virke enkelt ved første blikk, men vil være en gjentatt oppgave hvis det blir gjort endringer i koden.
Alternativt kan vi skrive en enhetstest som kan fungere som min validator så lenge forretningslogikken forblir den samme. Enhetstest saken vil ikke endres selv om vi endrer koden. Så la oss skrive en enhetstestsak for koden ovenfor.
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 ovennevnte testkode? Legg merke til de to Assert-uttalelsene. De sørger for at testen bare passerer hvis de to linjene mottar sanne og usanne fra de respektive IsPhoneValid-funksjonene.
Du vil spørre hva er fordelene med å skrive denne test saken? Vel, hvis du har tusenvis av telefonnumre å validere i et virkelighetsnært scenario, trenger du ikke å verifisere manuelt hver gang feilsøkeren treffer koden. Bare ring testkoden tusenvis av ganger, og den vil fortelle deg hvilke tester som har bestått, og hvilke som mislyktes. Nå trenger du bare å inspisere de mislykkede.
Tips for enhetstesting
- Bruk alltid et verktøy eller rammeverk som støtter språket ditt. Verktøy gjør det enkelt å utvikle enhetstesttilfeller. Du kan ende opp med å sette inn ekstra innsats ellers.
- Selv om det anbefales for alt, er det noen ganger praktisk å hoppe over koder som er enkle og ikke direkte påvirker atferden til systemet. For eksempel kan getter- og setterkoder være mindre fokusert på.
- Ikke hopp over koder som direkte påvirker systemet eller som er avgjørende for implementeringen av virksomhetslogikken.
- Bruk testdata som ligner produksjonsdata.
- Isoler koden din. Hvis koden din er avhengig av data fra databasen, må du ikke skrive en prøvesak for å ringe til databasen og få verdier. I stedet oppretter du et grensesnitt og håner API og databasesamtaler.
- Før du løser en feil som oppstår som følge av enhetstesting, må du skrive test saken som utsetter mangelen. Det er tre grunner til å gjøre det:
- Du vil være i stand til å fange regresjonsfeilene som oppstår som en løsning.
- Nå er test saken din mer omfattende.
- Ofte er en utvikler for lat til å oppdatere testsakene sine når de først er skrevet.
- I tillegg til å skrive testtilfeller som bekrefter forretningslogikken, kan du også skrive saker som tester kodenes ytelse. Spesielt når koder involverer looping, er ytelsen det mest berørte området.
Ting å huske
- Enhetstesters tilfeller bør være uavhengig av
- Koden som skal testes - Enhver endring i koden skal ikke kreve endring i enhetens testtilstand med mindre virksomhetslogikken i seg selv endres. For eksempel, hvis logikken nå krever at et gyldig telefonnummer alltid skal begynne med '+', må enhetstest saken endres, ellers ikke.
- Den andre koden - Det skal ikke være noen interaksjon eller avhengighet med noe annet stykke kode eller databaseverdi eller noe slikt. En enhet skal isoleres når du testes.
- Følg klare og konsistente navnekonvensjoner for testsakene dine. Det gjør det lettere å spore scenariene. Du kan også bruke versjonskontrollverktøy for å holde oversikt over testsakene dine.
- Aldri pass koden din til neste fase før den er gjort, feilene er løst og testet på nytt.
- Det viktigste er at du gjør det til en vane. Dette er en kodingspraksis som må inkuleres. Jo mer du koder uten enhetstesting, desto mer feilutsatt er koden.
Karriere i enhetstesting
Selv om enhetstesting ikke er noe felt i sin helhet, er det likevel en ekstra pil i kviseren din. Det er en god kodingspraksis, og når foretrekkes ikke gode kodere?
Konklusjon
Det kan ubestridt konkluderes med at enhetstesting kan være enkelt noen ganger og komplisert andre ganger. Det er når verktøyene og rammene reddes. Selv når enhetstesting er utført, er ikke koden feilfeil helt. Det er når testprosedyrene på neste nivå sparker i gang. Blant alle disse usikkerhetene, er det eneste som er sikker på at enhetstesting er nødvendig.
Anbefalte artikler
Dette har vært en guide til enhetstesting. Her diskuterte vi viktigheten, tipsene, verktøyene, karrieren og typer enhetstesting med eksemplene. Du kan også gå gjennom andre foreslåtte artikler for å lære mer -
- Testing av intervjuspørsmål
- Nettprøving
- Defekte livssyklus i test av programvare
- Karrierer innen programvaretesting
- Liste over testrammer for Java