Menu

Sleutel tot succesvolle unit-tests - Hoe ontwikkelaars hun eigen code testen?

key successful unit testing how developers test their own code

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Black Box-testers het maakt niet uit wat het testen van eenheden is. Hun belangrijkste doel is om de applicatie te valideren tegen de vereisten zonder in te gaan op de implementatiedetails.

Maar als een curiositeit of Out of the box denken , heb je je ooit afgevraagd hoe ontwikkelaars hun code testen? Welke methode gebruiken ze om te testen voordat ze code vrijgeven om te testen? Hoe is dev-testing belangrijk in een agile proces? Het antwoord op dit alles is Unit Testing. Ik wil je informeren over het belang van Unit Testing, zodat ontwikkel- en testteams beter kunnen samenwerken om een ​​uitstekende applicatie te ontwerpen, testen en vrijgeven.

Wie weet zullen sommigen van jullie in de toekomst zelfs overschakelen op white box-testen en deze codevalidatie- en verbeteringstechnieken gebruiken!

Testen van een eenheid

Wat je leert:

Wat is het testen van eenheden?

Unit Testing is geen nieuw concept. Het is er al sinds de begintijd van het programmeren. Meestal ontwikkelaars en soms Witte doos testers schrijf eenheidstests om de codekwaliteit te verbeteren door elke eenheid van de code te verifiëren die wordt gebruikt om functionele vereisten te implementeren (ook bekend als test-drive ontwikkeling TDD of test-first development).

De meesten van ons kennen misschien de klassieke definitie -
'Unit Testing is de methode om het kleinste stukje testbare code te verifiëren tegen zijn doel.' Als het doel of de vereiste is mislukt, is de unit-test mislukt.

In eenvoudige bewoordingen betekent het: een stuk code schrijven (eenheidstest) om de code (eenheid) te verifiëren die is geschreven voor het implementeren van vereisten.

Unit testen in SDLC

Unit testen in SDLC

Bij het testen van eenheden gebruiken ontwikkelaars handmatige of geautomatiseerde tests om ervoor te zorgen dat elke eenheid in de software voldoet aan de eisen van de klant. Deze eenheid kan een individuele functie, object, methode, procedure of module in de te testen software zijn.

Door eenheidstests te schrijven om de afzonderlijke eenheden te testen, wordt het schrijven van uitgebreide tests eenvoudiger omdat alle eenheden worden samengesteld. Tijdens softwareontwikkeling wordt dit gedaan als het eerste testniveau.

Belang van het schrijven van unit-tests

Unit Testing wordt gebruikt om robuuste softwarecomponenten te ontwerpen die helpen bij het onderhouden van code en het elimineren van de problemen in code-eenheden. We kennen allemaal het belang van het opsporen en verhelpen van defecten in de vroege fase van de softwareontwikkelingscyclus. Dit testen dient hetzelfde doel.

Het is een integraal onderdeel van het agile softwareontwikkelingsproces. Wanneer een nachtelijke build-run unit test suite moet draaien en rapport moet worden gegenereerd. Als een van de unit-tests is mislukt, mag het QA-team die build niet accepteren voor verificatie.

Als we dit als een standaardproces zouden instellen, zouden veel defecten worden opgemerkt in de vroege ontwikkelingscyclus, wat veel testtijd bespaart.

Ik weet dat veel ontwikkelaars een hekel hebben aan het schrijven van unit-tests. Ze negeren of schrijven slechte unit-testcases vanwege strakke planning of gebrek aan ernst (ja ze schrijven lege unit-tests, dus 100% van hen slaagt met succes ;-)). Het is belangrijk om goede unit-tests te schrijven of helemaal niet te schrijven. Het is nog belangrijker om te voorzien voldoende tijd en een ondersteunende omgeving voor echte voordelen.

Testmethoden voor eenheden

Het kan op 2 manieren worden uitgevoerd:

  1. Handmatig testen
  2. Geautomatiseerd testen

In Handmatig testen voert de tester handmatig testgevallen uit zonder gebruik te maken van een automatiseringstool. Hier wordt elke fase van de test handmatig uitgevoerd. Handmatig testen is vervelend, vooral voor tests die repetitief zijn en meer inspanning vereisen om testcases te maken en uit te voeren. Handmatig testen vereist geen kennis van een testtool.

Het is een feit dat 100% automatisering niet mogelijk is en dat er dus altijd een bepaald niveau van handmatige tests zal worden uitgevoerd.

In Geautomatiseerd testen, Automatiseringstools voor softwaretests worden gebruikt om de tests / testgevallen te automatiseren. De automatiseringstool kan uw test opnemen en opslaan en deze kan zo vaak als nodig opnieuw worden afgespeeld zonder verdere menselijke tussenkomst.

Deze tools kunnen zelfs testgegevens in het te testen systeem invoeren, de verwachte resultaten vergelijken met de werkelijke resultaten en automatisch de rapporten genereren. De initiële kosten voor het opzetten van testautomatiseringstools zijn echter hoog.

Technieken binnen unit-testen

# 1) White box testen:

hoe testcases te schrijven vanuit vereisten

Bij white-box testen kent de tester de interne structuur van de software inclusief de code en kan hij deze toetsen aan het ontwerp en de eisen. Vandaar dat white box-testen ook wel bekend staan ​​als transparant testen ​

witte doos testen

# 2) Black box-testen:

Bij black-box-testen kent de tester de interne structuren noch de code van de software.

black box testen

# 3) Grijze doos testen:

Dit wordt ook wel semi-transparante techniek testen wat betekent, de testers zijn zich slechts gedeeltelijk bewust van de interne structuur, functies en ontwerpen samen met de vereisten. Foutopsporing wordt gedaan door daadwerkelijke invoer van de front-end om exacte gegevens in de back-end te krijgen. De grijze doos wordt daarom beschouwd als een combinatie van black box en white box testtechnieken.

Grijze doos testen

Gray box-testen omvatten de volgende soorten testen:

  • Matrix testen.
  • Patroon testen.
  • Orthogonale patroontesten.
  • Regressietesten.

Voordelen van het testen van eenheden

  1. Het proces wordt wendbaar: Voor het toevoegen van nieuwe functies of features aan de bestaande software moeten we wijzigingen aanbrengen in de oude code. Maar het veranderen van dingen in de reeds geteste code kan zowel riskant als kostbaar zijn.
  2. Codekwaliteit verbetert: De kwaliteit van de code wordt automatisch verbeterd wanneer de unit wordt getest. De bugs die tijdens deze test zijn geïdentificeerd, worden opgelost voordat deze worden verzonden voor de integratietestfase. Resulteren in robuust ontwerp en ontwikkeling terwijl ontwikkelaars testcases schrijven door eerst de specificaties te begrijpen.
  3. Detecteert vroegtijdig bugs: Terwijl ontwikkelaars unit-tests uitvoeren, detecteren ze bugs vroeg in de levenscyclus van softwareontwikkeling en lossen ze deze op. Dit omvat gebreken of ontbrekende onderdelen in de specificatie, evenals bugs in de implementatie van de programmeur.
  4. Gemakkelijkere wijzigingen en vereenvoudigde integraties: Door unit-tests uit te voeren, kan de ontwikkelaar de code gemakkelijk herstructureren, wijzigingen aanbrengen en de code onderhouden. Het maakt het testen van de code na integratie ook veel gemakkelijker. Door een probleem op te lossen in Unit Testing, kunnen veel andere problemen worden opgelost die zich voordoen in latere ontwikkelings- en testfasen
  5. Documentatie beschikbaarheid: Ontwikkelaars die de functionaliteit in een later stadium onderzoeken, kunnen de documentatie van de unit-test raadplegen en kunnen de unit-testinterface gemakkelijk vinden en corrigeren of snel en gemakkelijk werken.
  6. Eenvoudig foutopsporingsproces: Het helpt bij het vereenvoudigen van het foutopsporingsproces. Als de test op enig moment mislukt, moet de code worden opgespoord, anders kan het proces zonder obstakels worden voortgezet.
  7. Lagere kost: Wanneer bugs worden gedetecteerd en opgelost tijdens het testen van eenheden, worden de kosten en ontwikkelingstijd verkort. Zonder deze test wordt het, als dezelfde bugs in een later stadium na de code-integratie worden gedetecteerd, moeilijker te traceren en op te lossen, waardoor het duurder wordt en de ontwikkelingstijd toeneemt.
  8. De volledigheid van de code kan worden aangetoond met behulp van unit-tests: Dit is nuttiger in het agile proces. Testers krijgen de functionele builds pas om te testen als de integratie is voltooid. Het aanvullen van de code kan niet worden gerechtvaardigd door aan te tonen dat u de code hebt geschreven en ingecheckt. Maar het uitvoeren van unit-tests kan de volledigheid van de code aantonen.
  9. Bespaart ontwikkeltijd: Het voltooien van de code kan meer tijd in beslag nemen, maar door minder fouten in de systeem- en acceptatietests kan de algehele ontwikkelingstijd worden bespaard.
  10. Code dekking kan worden gemeten

Eenheidstestcyclus

Eenheidstestcyclus

(beeld bron ​

Wat maakt een goede unit-test?

Nou, ik ben niet de juiste persoon om te vertellen wat een goede Unit Test is, maar op basis van mijn observaties bij verschillende projecten kan ik de kenmerken van een goede Unit Test vertellen. De slechte Unit Test voegt geen waarde toe aan het project. In plaats daarvan stijgen de projectkosten aanzienlijk door het schrijven en beheren van slechte unit-tests.

Hoe schrijf je goede unit-tests?

  • Een unit-test moet worden geschreven om een ​​enkele code-eenheid te verifiëren en niet de integratie.
  • Kleine en geïsoleerde unit-tests met duidelijke naamgeving zouden het schrijven en onderhouden heel gemakkelijk maken.
  • Het wijzigen van een ander deel van de software heeft geen invloed op de Unit-test als deze zijn geïsoleerd en geschreven voor een specifieke code-eenheid.
  • Het zou snel moeten werken
  • Een unit-test moet herbruikbaar zijn

Unit Testing Frameworks

Unit Testing-frameworks worden meestal gebruikt om unit-tests snel en gemakkelijk te schrijven. De meeste programmeertalen ondersteunen geen unit-testen met de ingebouwde compiler. Open source en commerciële tools van derden kunnen worden gebruikt om het testen van eenheden nog leuker te maken.

Lijst met populaire Instrumenten voor het testen van eenheden voor verschillende programmeertalen:

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

Misvattingen en waarheden

  • Het kost meer tijd om code te schrijven met Unit-testcases, en daar hebben we geen tijd voor. In werkelijkheid zou het je ontwikkelingstijd op de lange termijn besparen.
  • Unit-tests zullen alle bugs vinden - dat zal niet gebeuren, aangezien de bedoeling van de Unit-test niet is om bugs te vinden, maar om robuuste softwarecomponenten te ontwikkelen die in latere stadia van SDLC minder defecten zullen hebben.
  • 100% codedekking betekent 100% testdekking - Dit garandeert niet dat de code foutloos is.

Hoe unit testen te accepteren?

Een goede unit-test kan worden uitgevoerd in 3 basisonderdelen.

  1. Schrijf de unit-testcode
  2. Voer de testcode van het apparaat uit om te controleren of deze voldoet aan de systeemvereisten
  3. Voer de softwarecode uit om te testen op eventuele defecten en of de code voldoet aan de systeemvereisten.

Als na het uitvoeren van de bovenstaande 3 stappen de code correct lijkt te zijn, wordt gezegd dat de unit-test is geslaagd. En als het niet aan de systeemvereisten voldoet, mislukt de test. In dit geval moet de ontwikkelaar de code opnieuw controleren en corrigeren.

In sommige gevallen is het nodig om de code te scheiden om deze test nauwkeuriger uit te voeren.

Beste oefening

Houd rekening met de onderstaande punten om de beste code te maken tijdens deze test:

  • Code moet sterk zijn: Er zijn gevallen waarin de test mislukt of in het ergste geval helemaal niet wordt uitgevoerd als de code wordt verbroken.
  • Begrijpelijk en redelijk: De code moet gemakkelijk te begrijpen zijn. Dit maakt het gemakkelijk voor de ontwikkelaar om de code te schrijven en zelfs andere ontwikkelaars die later aan de code zullen werken, zullen het gemakkelijk vinden om fouten op te sporen.
  • Zou het enige geval moeten zijn: Tests die meerdere cases in één definiëren, zijn complex om mee te werken. Het schrijven van één casecode is dus de beste praktijk, waardoor de code gemakkelijker te begrijpen en te debuggen is.
  • Geautomatiseerde tests toestaan: De ontwikkelaars moeten ervoor zorgen dat de test in geautomatiseerde vorm wordt uitgevoerd. Het moet in een continu leveringsproces of integratieproces zijn.

Andere punten waarmee u rekening moet houden, zijn:

  • In plaats van testcases te maken voor alle condities, concentreer je je op de test die het gedrag van het systeem beïnvloedt.
  • Er is een kans dat de bug zich opnieuw voordoet vanwege de cache van de browser.
  • Testcases mogen niet onderling afhankelijk zijn.
  • Let ook op de conditie van de lus.
  • Plan de testcases vaker.

Gevolgtrekking

Het testen van eenheden komt in beeld wanneer het nodig is om elke functie afzonderlijk te testen. Het is veel redelijker om tijdens deze tests bugs op te sporen en op te lossen en zo tijd en kosten te besparen, in plaats van deze in de latere fase van softwareontwikkeling te vinden.

Hoewel het veel voordelen biedt, zijn er ook beperkingen aan het gebruik ervan. Strenge discipline en consistentie zijn vereist tijdens het softwareontwikkelingsproces om beperkingen te overwinnen en de beoogde voordelen te behalen.

Uw opmerkingen zijn zeer welkom!
Wat zijn uw observaties als black box-tester over Unit Testing in uw team? Heeft iemand een beter idee voor succesvolle Unit Testing?

Aanbevolen literatuur

^