key successful unit testing how developers test their own code
Black Box testere bryr meg ikke om enhetstesting. Hovedmålet deres er å validere søknaden mot kravene uten å gå inn på implementeringsdetaljene.
Men som en kuriositet eller Utenfor boksen å tenke , har du noen gang lurt på hvordan utviklere tester koden sin? Hvilken metode bruker de for å teste før de gir ut kode for testing? Hvordan er dev-testing viktig i en smidig prosess? Svaret på alt dette er enhetstesting. Jeg vil lære deg viktigheten av Unit Testing, slik at utviklings- og testteam kan jobbe mer sammen for å designe, teste og frigjøre en utmerket applikasjon.
Hvem vet i fremtiden at noen av dere til og med kan bytte til testing av hvit boks og bruke disse kodevaliderings- og forbedringsteknikkene!
Hva du vil lære:
Hva er enhetstesting?
Enhetstesting er ikke et nytt konsept. Det har vært der siden de første dagene av programmeringen. Vanligvis utviklere og noen ganger Hvite boks testere skriv enhetstester for å forbedre kodekvaliteten ved å verifisere hver enhet av koden som brukes til å implementere funksjonelle krav (aka testkjørt utvikling TDD eller test-første utvikling).
De fleste av oss kjenner kanskje den klassiske definisjonen -
'Enhetstesting er metoden for å verifisere den minste biten av testbar kode mot dens formål.' Hvis formålet eller kravet mislyktes, har enhetstesten mislyktes.
Med enkle ord betyr det - å skrive et stykke kode (enhetstest) for å verifisere koden (enheten) som er skrevet for å implementere krav.
Enhetstesting i SDLC
I Enhetstesting bruker utviklere manuelle eller automatiserte tester for å sikre at hver enhet i programvaren oppfyller kundens krav. Denne enheten kan være en individuell funksjon, gjenstand, metode, prosedyre eller modul i programvaren som testes.
Å skrive enhetstester for å teste de enkelte enhetene gjør det lettere å skrive omfattende tester når alle enhetene er satt sammen. Under programvareutvikling gjøres det som det første testnivået.
Viktigheten av skriveenhetstester
Enhetstesting brukes til å designe robuste programvarekomponenter som hjelper med å opprettholde koden og eliminere problemene i kodenheter. Vi vet alle viktigheten av å finne og fikse feil i den tidlige fasen av programvareutviklingssyklusen. Denne testen har samme formål.
Det er en integrert del av den smidige programvareutviklingsprosessen. Når en testpakke for bygging av enhetene skal kjøres hver natt, og rapporten skal genereres. Hvis noen av enhetstestene har mislyktes, bør ikke QA-teamet godta den bygningen for verifisering.
Hvis vi setter dette som en standard prosess, vil mange mangler bli fanget opp i den tidlige utviklingssyklusen, og sparer mye testtid.
Jeg vet at mange utviklere hater å skrive enhetstester. De ignorerer eller skriver dårlige enhetstestsaker på grunn av stramt planlagt eller mangel på alvor (ja, de skriver tomme enhetstester, så 100% av dem består vellykket ;-)). Det er viktig å skrive gode enhetstester eller ikke skrive dem i det hele tatt. Det er enda viktigere å tilby nok tid og et støttende miljø for reelle fordeler.
Enhetstestmetoder
Det kan utføres på to måter:
- Manuell testing
- Automatisert testing
I Manuell testing , utfører testeren manuelt testsaker uten å bruke noe automatiseringsverktøy. Her utføres hvert trinn i testen manuelt. Manuell testing er kjedelig spesielt for tester som er repeterende og krever mer innsats for å lage og utføre testsaker. Manuell testing krever ikke kunnskap om noe testverktøy.
Det er et faktum at 100% av automatisering ikke er mulig, og det vil derfor alltid være noen grad av manuell testing utført.
I Automatisert testing, programvare testing automatiseringsverktøy brukes til å automatisere test / test tilfeller. Automatiseringsverktøyet kan registrere og lagre testen din, og den kan spilles av så mange ganger som nødvendig uten ytterligere menneskelig inngripen.
Disse verktøyene kan til og med legge inn testdata i systemet som testes, i tillegg til at de kan sammenligne de forventede resultatene med de faktiske resultatene og automatisk generere rapportene. Imidlertid er den opprinnelige kostnaden for å sette opp testautomatiseringsverktøy høy.
Teknikker innen enhetstesting
# 1) Testing av hvit boks:
hva er Linux og unix operativsystem
Ved testing av hvit boks kjenner testeren programvarens interne struktur, inkludert koden, og kan teste den mot design og krav. Derfor er hvitboksprøving også kjent som gjennomsiktig testing .
# 2) Black box testing:
I black-box testing kjenner ikke testeren de interne strukturene hverken koden til programvaren.
# 3) Testing av grå boks:
Dette blir også referert til som semi-gjennomsiktig teknikk testing som betyr, testerne er bare delvis klar over det av den interne strukturen, funksjonene og designene sammen med kravene. Feilsøking gjøres ved faktiske innspill fra front-enden for å få eksakte data i back-end. Den grå boksen betraktes derfor som en kombinasjon av testteknikker for svart boks og hvit boks.
Testing av grå bokser dekker følgende typer testing:
- Matrix Testing.
- Mønster testing.
- Ortogonal mønsterprøving.
- Regresjonstesting.
Fordeler med enhetstesting
- Prosessen blir smidig: For å legge til nye funksjoner eller funksjoner til den eksisterende programvaren, må vi gjøre endringer i den gamle koden. Men å endre ting til den allerede testede koden kan være både risikabelt og kostbart.
- Kodekvaliteten forbedres: Kvaliteten på koden forbedres automatisk når enhetstesting er gjort. Feilene som ble identifisert under denne testingen, blir løst før de sendes til integrasjonsprøvefasen. Resultat i robust design og utvikling når utviklere skriver testtilfeller ved å forstå spesifikasjonene først.
- Oppdager feil tidlig: Når utviklere kjører enhetstester, oppdager de feil tidlig i programvarens utvikling og løser dem. Dette inkluderer feil eller manglende deler i spesifikasjonen, samt feil i programmererens implementering.
- Enklere endringer og forenklede integrasjoner: Å gjøre enhetstesting gjør det enkelt for utvikleren å restrukturere koden, gjøre endringer og vedlikeholde koden. Det gjør det også enklere å teste koden etter integrering. Å fikse et problem i Unit Testing kan løse mange andre problemer som oppstår i senere utviklings- og testfaser
- Dokumentasjon tilgjengelighet: Utviklere som ser på funksjonalitet på et senere tidspunkt, kan henvise til dokumentasjonen for enhetstesting og kan enkelt finne enhetstestgrensesnittet og korrigere eller jobbe raskt og enkelt.
- Enkel feilsøkingsprosess: Det hjelper med å forenkle feilsøkingsprosessen. Hvis testen mislykkes på noe tidspunkt, må koden feilsøkes, ellers kan prosessen fortsettes uten hindringer.
- Lavere kostnad: Når feil oppdages og løses under enhetstesting, reduseres kostnad og utviklingstid. Uten denne testen, hvis de samme feilene blir oppdaget på et senere tidspunkt etter kodeintegrasjonen, blir det vanskeligere å spore og løse, noe som gjør det mer kostbart og øker utviklingstiden.
- Kodens fullstendighet kan demonstreres ved hjelp av enhetstester: Dette er mer nyttig i den smidige prosessen. Testere får ikke de funksjonelle byggene til å teste før integrasjonen er fullført. Utfylling av koden kan ikke rettferdiggjøres ved å vise at du har skrevet og sjekket inn koden. Men å kjøre enhetstester kan demonstrere kodens fullstendighet.
- Sparer utviklingstid: Fullføring av koden kan ta mer tid, men på grunn av færre feil i system- og aksepttestingen kan den samlede utviklingstiden spares.
- Kodedekning kan måles
Enhetstestsyklus
[bilde kilde ]
Hva gjør en god enhetstest?
Vel, jeg er ikke den rette personen til å fortelle hva som gjør en god enhetstest, men basert på mine observasjoner om forskjellige prosjekter kan jeg fortelle egenskapene til en god enhetstest. Den dårlige enhetstesten tilfører ikke prosjektet verdi. I stedet øker prosjektkostnadene betydelig ved å skrive og administrere dårlige enhetstester.
Hvordan skriver jeg gode enhetstester?
- En enhetstest skal skrives for å bekrefte en enkelt kodeenhet og ikke integrasjonen.
- Små og isolerte enhetstester med tydelig navngiving vil gjøre det veldig enkelt å skrive og vedlikeholde.
- Endring av en annen del av programvaren skal ikke påvirke enhetstesten hvis de er isolert og skrevet for en bestemt kodeenhet.
- Den skal løpe raskt
- Enhetstest bør være gjenbrukbar
Enhetstestingsrammer
Enhetstestingsrammer brukes mest til å skrive enhetstester raskt og enkelt. De fleste av programmeringsspråkene støtter ikke enhetstesting med den innebygde kompilatoren. Tredjeparts åpen kildekode og kommersielle verktøy kan brukes til å gjøre enhetstesting enda morsommere.
Liste over populære Enhetstestverktøy for forskjellige programmeringsspråk:
- Java-rammeverk - JUnit
- PHP rammeverk - PHPUnit
- C ++ rammer - UnitTest ++ og Google C ++
- .NET rammeverk - NUnit
- Python framework - py.test
Misforståelser og sannheter
- Det tar mer tid å skrive kode med Unit test-tilfeller, og vi har ikke tid til det - i virkeligheten vil det spare tid for utvikling på lang sikt.
- Enhetstesting vil finne alle feil - det vil ikke, da hensikten med enhetstesten ikke er å finne feil, men utvikle robuste programvarekomponenter som vil ha færre feil i senere stadier av SDLC.
- 100% kodedekning betyr 100% testdekning - Dette garanterer ikke at koden er feilfri.
Hvordan godta enhetstesting?
God enhetstesting kan utføres i 3 grunnleggende deler.
- Skriv enhetens testkode
- Kjør enhetstestkoden for å sjekke om den oppfyller systemkravet
- Utfør programvarekoden for å teste for eventuelle feil og om koden oppfyller systemkravet.
Etter å ha utført de tre trinnene ovenfor, hvis koden ser ut til å være riktig, sies det at enhetstesten er bestått. Og hvis den ikke oppfyller systemkravene, mislykkes testen. I dette tilfellet må utvikleren kontrollere og korrigere koden på nytt.
I noen tilfeller er det nødvendig å skille koden for å utføre denne testen mer nøyaktig.
Beste praksis
Vurder følgende punkter for å lage den beste koden under denne testen:
- Koden skal være sterk: Det er tilfeller der testen mislykkes eller i verste fall ikke blir utført i det hele tatt hvis koden er ødelagt.
- Forståelig og rimelig: Koden skal være lett å forstå. Dette gjør det enkelt for utvikleren å skrive koden, og til og med andre utviklere som vil jobbe med koden senere vil finne det enkelt å feilsøke.
- Bør være enkeltsaken: Tester som definerer flere tilfeller i ett, er kompliserte å jobbe med. Dermed er det å skrive en enkelt sakskode best praksis, noe som gjør koden lettere å forstå og feilsøke.
- Tillat automatiserte tester: Utviklerne bør sørge for at testen kjører i automatisert form. Det skal være i en kontinuerlig leveringsprosess eller integrasjonsprosess.
Andre punkter du må huske på er som følger:
- I stedet for å lage testsaker for alle forhold, fokuser du på testen som påvirker systemets oppførsel.
- Det er sjanser for at feilen kommer igjen på grunn av nettleserens cache.
- Test tilfeller bør ikke være gjensidig avhengige.
- Vær også oppmerksom på sløyfetilstanden.
- Planlegg testsakene oftere.
Konklusjon
Enhetstesting kommer inn i bildet når det er nødvendig å teste hver funksjon separat. Det er mye rimelig å oppdage og fikse feil under denne testingen og spare tid og kostnader, i stedet for å finne på det senere stadiet av programvareutvikling.
Selv om det gir mange fordeler, er det også begrensninger involvert i å bruke det. Det kreves streng disiplin og konsistens gjennom programvareutviklingsprosessen for å overvinne begrensninger og få de tiltenkte fordelene.
Kommentarene dine er hjertelig velkomne!
Som en svart boks tester, hva er dine observasjoner om enhetstesting på teamet ditt? Har noen en bedre idé for vellykket enhetstesting?
Anbefalt lesing
- Forskjellene mellom enhetstesting, integrasjonstesting og funksjonstesting
- 20 mest populære enhetstestverktøy i 2021
- Skriveenhetstester med Spock Framework
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Viktige forskjeller mellom Black Box Testing og White Box Testing
- Lastetesting med HP LoadRunner-opplæringsprogrammer
- Forskjellen mellom stasjonær, klientservertesting og nettesting
- Hva er gammatesting? Den siste testfasen