Menu

Nøglen til vellykket enhedstest - Hvordan udviklere tester deres egen kode?

key successful unit testing how developers test their own code

Prøv Vores Instrument Til At Fjerne Problemer

Black Box testere er ligeglad med enhedstest. Deres hovedmål er at validere ansøgningen mod kravene uden at gå i detaljerne om implementeringen.

Men som en nysgerrighed eller Uden for boksen tænker , har du nogensinde spekuleret på, hvordan udviklere tester deres kode? Hvilken metode bruger de til at teste, før de frigiver kode til test? Hvordan er udvikling af test vigtig i en smidig proces? Svaret på alt dette er enhedstest. Jeg vil uddanne dig om vigtigheden af ​​Unit Testing, så udviklings- og testteams kan arbejde mere sammen for at designe, teste og frigive en fremragende applikation.

Hvem ved i fremtiden, at nogle af jer måske endda skifter til test af hvide kasser og bruger disse kodevaliderings- og forbedringsteknikker!

Enhedstest

Hvad du lærer:

Hvad er enhedstestning?

Enhedstest er ikke et nyt koncept. Det har været der siden de første dage af programmeringen. Normalt udviklere og nogle gange Hvide boks testere skriv enhedstest for at forbedre kodekvaliteten ved at verificere hver enhed af koden, der bruges til at implementere funktionelle krav (også kaldet testdrevet udvikling TDD eller test-første udvikling).

De fleste af os kender måske den klassiske definition -
'Enhedstestning er metoden til at verificere det mindste stykke testbar kode i forhold til dets formål.' Hvis formålet eller kravet mislykkedes, er enhedstesten mislykket.

Med enkle ord betyder det - at skrive et stykke kode (enhedstest) for at verificere den kode (enhed), der er skrevet til implementeringskrav.

Enhedstest i SDLC

Enhedstest i SDLC

I enhedstest bruger udviklere manuelle eller automatiske tests for at sikre, at hver enhed i softwaren opfylder kundens krav. Denne enhed kan være en individuel funktion, objekt, metode, procedure eller modul i softwaren, der testes.

Skrivning af enhedstest for at teste de enkelte enheder gør det lettere at skrive omfattende test, når alle enhederne er sammensat. Under softwareudvikling gøres det som det første testniveau.

Betydningen af ​​skriveenhedstest

Enhedstest bruges til at designe robuste softwarekomponenter, der hjælper med at vedligeholde kode og fjerne problemer i kodeenheder. Vi ved alle vigtigheden af ​​at finde og rette mangler i den tidlige fase af softwareudviklingscyklussen. Denne test tjener det samme formål.

Det er en integreret del af den agile softwareudviklingsproces. Når en test-suite, der kører om natten, skal køre, og der skal genereres en rapport. Hvis nogen af ​​enhedstestene er mislykkede, bør QA-teamet ikke acceptere den build til verifikation.

Hvis vi indstiller dette som en standardproces, vil mange fejl blive fanget i den tidlige udviklingscyklus, hvilket sparer meget testtid.

Jeg ved, at mange udviklere hader at skrive enhedstest. De ignorerer enten eller skriver dårlige enhedstestsager på grund af stramt planlagt eller manglende alvor (ja de skriver tomme enhedstest, så 100% af dem bestå med succes ;-)). Det er vigtigt at skrive gode enhedstest eller slet ikke skrive dem. Det er endnu vigtigere at levere tilstrækkelig tid og et støttende miljø til reelle fordele.

Enhedstestmetoder

Det kan udføres på 2 måder:

  1. Manuel test
  2. Automatiseret test

I Manuel test , udfører testeren manuelt testsager uden at bruge noget automatiseringsværktøj. Her udføres hvert trin i testen manuelt. Manuel test er kedelig især for tests, der er gentagne og kræver mere indsats for at oprette og udføre testsager. Manuel test kræver ikke kendskab til noget testværktøj.

Det er en kendsgerning, at 100% af automatisering ikke er mulig, og der vil derfor altid være et niveau af manuel test udført.

I Automatiseret test, softwaretest automatiseringsværktøjer bruges til at automatisere test / test tilfælde. Automatiseringsværktøjet kan registrere og gemme din test, og den kan afspilles så mange gange som nødvendigt uden yderligere menneskelig indgriben.

Disse værktøjer kan endda indtaste testdata i det system, der testes, såvel som det kan sammenligne de forventede resultater med de faktiske resultater og automatisk generere rapporterne. De oprindelige omkostninger ved opsætning af testautomationsværktøjer er dog høje.

Teknikker inden for enhedstest

# 1) Hvid boks test:

hvad er den bedste software til fjernadgang

Ved test af hvidboks kender testeren softwarens interne struktur inklusive koden og kan teste den mod designet og kravene. Derfor er testning af hvid boks også kendt som gennemsigtig test .

test af hvid boks

# 2) Test af sort boks:

I sort-boks-test kender testeren ikke de interne strukturer hverken softwarekoden.

test af sort boks

# 3) Test af grå boks:

Dette kaldes også semi-gennemsigtig teknik test hvilket betyder, testerne er kun delvist opmærksomme af den interne struktur, funktioner og design sammen med kravene. Fejlfinding foretages ved faktisk input fra frontend for at få nøjagtige data i backend. Den grå kasse betragtes derfor som en kombination af testteknikker for sort kasse og hvid kasse.

Test af grå boks

Test af grå boks dækker følgende typer test:

  • Matrixtest.
  • Mønster test.
  • Ortogonal mønstertest.
  • Regressionstest.

Fordele ved enhedstest

  1. Processen bliver smidig: For at tilføje nye funktioner eller funktioner til den eksisterende software er vi nødt til at foretage ændringer i den gamle kode. Men at ændre ting til den allerede testede kode kan være både risikabelt og dyrt.
  2. Kodekvaliteten forbedres: Kodens kvalitet forbedres automatisk, når enhedstesten er udført. De fejl, der er identificeret under denne test, rettes, inden de sendes til integrationstestfasen. Resultat i robust design og udvikling, når udviklere skriver testcases ved først at forstå specifikationerne.
  3. Registrerer fejl tidligt: Da udviklere kører enhedstest, opdager de fejl tidligt i softwareudviklingens livscyklus og løser dem. Dette inkluderer mangler eller manglende dele i specifikationen samt fejl i programmørens implementering.
  4. Lettere ændringer og forenklede integrationer: At lave enhedstest gør det nemt for udvikleren at omstrukturere koden, foretage ændringer og vedligeholde koden. Det gør det også meget lettere at teste koden efter integration. Løsning af et problem i Unit Testing kan løse mange andre problemer, der opstår i senere udviklings- og testfaser
  5. Dokumentation tilgængelighed: Udviklere, der ser på funktionaliteten på et senere tidspunkt, kan henvise til dokumentationen til enhedstest og kan let finde enhedstestgrænsefladen og rette eller arbejde hurtigt og nemt.
  6. Nem fejlretningsproces: Det hjælper med at forenkle fejlretningsprocessen. Hvis testen mislykkes på noget tidspunkt, skal koden debugges, ellers kan processen fortsættes uden forhindringer.
  7. Lavere omkostninger: Når fejl opdages og løses under enhedstest, reduceres omkostninger og udviklingstid. Uden denne test bliver det sværere at spore og løse, hvis de samme fejl opdages på et senere tidspunkt efter kodeintegrationen, hvilket gør det dyrere og øger udviklingstiden.
  8. Kodens fuldstændighed kan demonstreres ved hjælp af enhedstest: Dette er mere nyttigt i den smidige proces. Testere får ikke de funktionelle builds til at teste, før integrationen er afsluttet. Kodefuldførelse kan ikke retfærdiggøres ved at vise, at du har skrevet og kontrolleret koden. Men at køre enhedstest kan demonstrere kodens fuldstændighed.
  9. Sparer udviklingstid: Kodefærdiggørelse kan tage mere tid, men på grund af færre fejl i test af system og accept kan den samlede udviklingstid spares.
  10. Kodedækning kan måles

Enhedstestcyklus

Enhedstestcyklus

(billede kilde )

Hvad gør en god enhedstest?

Jeg er ikke den rigtige person til at fortælle, hvad der gør en god enhedstest, men på baggrund af mine observationer på forskellige projekter kan jeg fortælle karakteristikaene ved en god enhedstest. Den dårlige enhedstest tilføjer ikke værdi til projektet. I stedet øger projektomkostningerne betydeligt ved at skrive og administrere dårlige enhedstests.

Hvordan skriver man gode enhedstest?

  • En enhedstest skal skrives for at bekræfte en enkelt kodeenhed og ikke integrationen.
  • Små og isolerede enhedstest med tydelig navngivning ville gøre det meget let at skrive og vedligeholde.
  • Ændring af en anden del af softwaren bør ikke påvirke enhedstesten, hvis de er isoleret og skrevet til en bestemt kodeenhed.
  • Det skal køre hurtigt
  • En enhedstest skal kunne genbruges

Enhedstestrammer

Enhedstestningsrammer bruges mest til at hjælpe med at skrive enhedstest hurtigt og nemt. De fleste programmeringssprog understøtter ikke test af enheder med den indbyggede compiler. Tredjeparts open source og kommercielle værktøjer kan bruges til at gøre enhedstest endnu sjovere.

Liste over populære Enhedstestværktøjer til forskellige programmeringssprog:

  1. Java-ramme - JUnit
  2. PHP ramme - PHPUnit
  3. C ++ rammer - UnitTest ++ og Google C ++
  4. .NET framework - NUnit
  5. Python-ramme - py.test

Misforståelser og sandheder

  • Det tager mere tid at skrive kode med Unit test-sager, og vi har ikke tid til det - I virkeligheden sparer det din udviklingstid i det lange løb.
  • Enhedstest finder alle fejl - Det vil det ikke, da hensigten med enhedstesten ikke er at finde fejl, men udvikler robuste softwarekomponenter, der vil have færre defekter i senere stadier af SDLC.
  • 100% kodedækning betyder 100% testdækning - Dette garanterer ikke, at koden er fejlfri.

Sådan accepteres test af enheden?

God enhedstest kan udføres i 3 grundlæggende dele.

  1. Skriv enhedstestkoden
  2. Kør enhedstestkoden for at kontrollere, om den opfylder systemkravet
  3. Udfør softwarekoden for at teste for eventuelle mangler, og om koden opfylder systemkravet.

Efter at have udført de ovennævnte 3 trin, hvis koden ser ud til at være korrekt, siges enhedstesten at være bestået. Og hvis den ikke opfylder systemkravene, mislykkes testen. I dette tilfælde skal udvikleren kontrollere og rette koden igen.

I nogle tilfælde er det nødvendigt at adskille koden for at udføre denne test mere præcist.

Bedste praksis

For at oprette den bedste kode under denne test skal du overveje nedenstående punkter:

  • Koden skal være stærk: Der er tilfælde, hvor testen mislykkes eller i værste tilfælde ikke bliver udført overhovedet, hvis koden er brudt.
  • Forståelig og rimelig: Koden skal være let at forstå. Dette gør det let for udvikleren at skrive koden, og selv andre udviklere, der efterfølgende vil arbejde på koden, vil finde det let at debugge.
  • Bør være den eneste sag: Test, der definerer flere tilfælde i en, er kompliceret at arbejde med. Således er det bedste at skrive en enkelt sagskode, hvilket gør koden lettere at forstå og debugge.
  • Tillad automatiserede tests: Udviklerne skal sørge for, at testen kører i en automatisk form. Det skal være i en kontinuerlig leveringsproces eller integrationsproces.

Andre punkter, der skal huskes, er som følger:

  • I stedet for at oprette testcases under alle forhold, skal du fokusere på den test, der påvirker systemets opførsel.
  • Der er chancer for, at fejlen gentager sig på grund af browserens cache.
  • Test tilfælde bør ikke være indbyrdes afhængige.
  • Vær også opmærksom på loop-tilstanden.
  • Planlæg testsagerne oftere.

Konklusion

Enhedstest kommer i billedet, når det er nødvendigt at teste hver funktion separat. Det er meget rimeligt at opdage og rette fejl under denne test og spare tid og omkostninger snarere end at finde på det senere stadium af softwareudvikling.

Mens det giver mange fordele, er der også begrænsninger forbundet med at bruge det. Der kræves streng disciplin og konsistens gennem softwareudviklingsprocessen for at overvinde begrænsningerne og få de tilsigtede fordele.

Dine kommentarer er meget velkomne!
Som en sort boks tester, hvad er dine observationer om enhedstestning på dit team? Har nogen en bedre idé til vellykket enhedstest?

Anbefalet læsning

^