Wat is testen van eenheden?
Unit testen is een vanzelfsprekend woord als men begrijpt wat met Unit wordt bedoeld. Een eenheid is het kleinst mogelijke stuk code dat logisch kan worden geïsoleerd van het systeem. Dit betekent dat elk stuk code dat invoer kan uitvoeren, een taak kan uitvoeren en uitvoer kan genereren, zelfs als het onafhankelijk is van het hele systeem of de oplossing, als een eenheid kan worden aangeduid. Het testen van dit stuk code om verwachte uitvoer op een gegeven set ingangen te genereren, wordt eenheidstesting genoemd.
Soorten eenheidstests
Laten we enkele typen unit-testen bespreken.
1) Handmatig testen
Bij handmatig testen van code moet de ontwikkelaar elke regel van de code handmatig debuggen en op nauwkeurigheid testen. Mogelijk is een stapsgewijze instructieset vereist als de functionaliteit complex is.
2) Geautomatiseerd testen
Bij automatiseringstests schrijft de ontwikkelaar code naar testcode. Dit wordt in het algemeen ondersteund door Unit Test-frameworks die niet in productie worden gebruikt. Op andere momenten kan een ontwikkelaar ervoor kiezen om testcode te schrijven zonder het framework en deze handmatig te becommentariëren voordat deze wordt geïmplementeerd.
Handmatig testen lijkt voor de meeste gevallen uiteraard tijdrovend. Maar in sommige gevallen is het bij het schrijven van geautomatiseerde testcases om elk scenario niet mogelijk te zijn, handmatig de voorkeur.
Waarom is het testen van eenheden belangrijk?
Om het belang van het testen van eenheden te begrijpen, moeten we naar het bredere beeld kijken. Het maakt deel uit van de Software Development Life Cycle. Laten we de andere delen kort bekijken om een beter inzicht te krijgen in de rol van eenheidstesten.
De bovenstaande afbeelding is een eenvoudige illustratie van een normale levenscyclus van softwareontwikkeling en de bijbehorende testprocessen. Onnodig te zeggen dat, afhankelijk van de structuur van het project, het hele proces varieert met de toevoeging en verwijdering van bepaalde componenten. Het testproces omvat echter zeer zeker vier typen zoals hieronder beschreven:
- Eenheidstesten - Het elementaire niveau van het gehele testproces. Dit wordt uitgevoerd door de ontwikkelaar van de component of een van zijn collega's. In het laatste geval wordt het in de softwarewereld vaak Peer Testing genoemd.
- Integratietest - Testen van de component van de unit met de directe bovenliggende module. Het doel is om te controleren of de component van de unit goed integreert met de andere componenten en geen defecten van andere componenten heeft veroorzaakt.
- Systeemtesten - Testen van het gehele systeem wanneer het apparaatonderdeel op zijn positie wordt geplaatst.
- Acceptatietesten - Meestal gedaan door bedrijven / klanten, wordt gecontroleerd of de uitkomst overeenkomt met de functionaliteit die de eindgebruiker verwacht.
Men kan dus heel goed zien dat alle testprocessen afhankelijk zijn van het elementaire testniveau. Als het elementaire testniveau niet wordt uitgevoerd, kunnen alle andere testen zinloos zijn.
Laten we zeggen dat u een code hebt die uit twee delen bestaat
- Bereken samengestelde rente.
- Voeg de rente toe aan de hoofdsom en bereken het looptijdvoordeel.
Laten we aannemen dat u geen van deze componenten hebt getest en direct bent overgegaan op systeemtesten. Bij het testen van het systeem doet zich een fout voor dat de volwassenheidswaarde onjuist is. Welk deel van de code bevat een fout?
- Het kan in de berekening van rente zijn.
- Het kan zijn bij het toepassen van de samenstellingslogica.
- Het kan een aanvulling zijn op de hoofdsom.
Zie, hoe het de inspanning nu verhoogt. Dit had allemaal voorkomen kunnen worden als beide codecomponenten op de eenheid waren getest.
Waarom is het testen van eenheden belangrijk?
- Het lost bugs alleen vroeg in de ontwikkelingsfase op. Dit bespaart veel tijd, moeite en kosten. Stel je voor dat er geen unit tests zouden worden uitgevoerd, de code zou van en naar het team voor kwaliteitsborging gaan voor heel eenvoudige problemen.
- Goede unit tests dienen ook voor het doel van gedetailleerde documentatie. Wanneer een ontwikkelaar unit-testgevallen schrijft, schrijft hij per ongeluk de verwachte functionaliteit van de code. Dit is gewoon niets anders dan documentatie die de werking van de code verklaart.
- Het maakt het gemakkelijk om code te wijzigen en te onderhouden. Nadat u de code hebt gewijzigd, voert u de tests opnieuw uit en altviool, worden alle defecten zonder gedoe opgevangen.
- Het dwingt ook modulariteit af. Unit-tests worden uitgevoerd op individuele componenten, wat betekent dat de code zo gedetailleerd mogelijk moet zijn. Dit zorgt ervoor dat de code toepasselijk in modules wordt verdeeld.
De andere kant van de medaille
Het heeft ook enkele nadelen. Hoewel de voordelen zwaarder wegen dan de nadelen en het wordt altijd aanbevolen om uw code in eenheden te testen, toch is het ook logisch om beide zijden van dezelfde medaille te kennen.
- Unit-testing, hoe grondig dan ook, kan soms niet alle fouten in de meest triviale code opvangen. Het is eenvoudigweg niet mogelijk om alle uitvoeringspaden te evalueren. Eenheidstests zijn dus vaak eenvoudige happy-path en negatieve scenario's.
- Het vereist van een ontwikkelaar dat hij out of the box denkt en probeert zijn code te breken. Dit is vaak moeilijk omdat de perceptie van een ontwikkelaar de voorkeur geeft aan de code.
Hulpmiddelen voor het testen van eenheden
Er zijn verschillende tools in de industrie om te helpen met geautomatiseerde unit-testgevallen. Zoals het doel is, maken ze het schrijven en uitvoeren van unit-testgevallen gemakkelijker voor de ontwikkelaar. Er is een wereld van unit testing frameworks voor de uitbetaling van ontwikkelaars. Enkele van de meest populaire en meest gebruikte tools worden hieronder vermeld.
JUnit
JUnit is een gratis te gebruiken testtool voor Java. Het wordt automatisch opgenomen in vele projectsjablonen die beschikbaar zijn met verschillende IDE's voor Java-ontwikkeling. Wat JUnit speciaal maakt, is dat het eerst de gegevens test en vervolgens de code test nadat de gegevens erin zijn ingevoerd. Het biedt ook beweringen om de testmethoden te identificeren.
NUnit
NUnit is naar .Net zoals JUnit naar Java is. Het heeft alle opvallende kenmerken van JUnit, maar voor ontwikkeling in .Net programmeertaal. Het ondersteunt ook het parallel uitvoeren van de tests.
PHPUnit
Vergelijkbaar met JUnit en NUnit, PHPUnit is een hulpmiddel voor PHP-ontwikkelaars. Het ondersteunt ook alle elementaire kenmerken van een goede testtool.
xUnit
Een ander raamwerk dat meer generiek is dan zijn tegenhangers is XUnit. Het ondersteunt meerdere talen zoals C ++, C #, ASP.Net, enz. Het beschikt ook over soortgelijke functies als die van andere tools die op de markt beschikbaar zijn.
Jtest
Parasoft Jtest is een plug-in van derden die gebruikmaakt van de open source frameworks zoals JUnit en oplossingen met één klik toevoegt om het leven gemakkelijker te maken. Met Jtest kunt u automatisch testcodes voor uw code genereren met slechts een paar klikken. Door deze taken te automatiseren, kan de ontwikkelaar aan de bedrijfslogica van de testcases werken.
QUnit
Een zeer populair framework voor het testen van JavaScript-eenheden. Het kan JavaScript-code zowel aan client- als serverzijde testen.
Jasmijn
Nog een veel gebruikte testtool voor JavaScript-frameworks. Het heeft belangrijke community-ondersteuning voor Angular, React, etc.
JMockIt
JMockIt is een open source tool die ook ondersteuning biedt voor het bespotten van de API-aanroepen met opname- en verificatiesyntaxis.
Voorbeeld van eenheidstestgeval
Een zeer basisvereiste voor elke testeenheid is de te testen code. Laten we aannemen dat we een functie hebben die valideert of de telefoonnummers correct zijn (qua formaat) of niet. Afhankelijk van de geografische locatie kan dit criterium ook variëren. We zullen de criteria dus niet benadrukken. In plaats daarvan zullen we ons concentreren op de eenheidstestcase.
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 moeten we dit stukje code testen.
We kunnen het handmatig testen door verschillende waarden in te voegen en de uitvoer te verifiëren. Dit lijkt misschien eenvoudig bij de eerste blik, maar het zal een herhaalde taak zijn als de code wordt gewijzigd.
Als alternatief kunnen we een eenheidstestcase schrijven die als mijn validator kan dienen, zolang de bedrijfslogica hetzelfde blijft. De unit-testcase verandert niet, zelfs niet als we de code wijzigen. Laten we daarom een unit-testcase voor de bovenstaande code schrijven.
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));
)
Dus hoe werkt de bovenstaande unit-testcode? Let op de twee beweringen. Ze zorgen ervoor dat de test alleen slaagt als de twee regels waar en onwaar ontvangen van de respectieve IsPhoneValid-functieoproepen.
U vraagt zich af wat de voordelen zijn van het schrijven van deze testcase? Nou, als je duizenden telefoonnummers hebt om te valideren in een real-world scenario, hoef je niet handmatig te verifiëren elke keer dat de debugger de code raakt. Roep eenvoudig de testcode duizenden keren aan en het zal u vertellen welke tests zijn geslaagd en welke niet. Nu hoeft u alleen de mislukte te inspecteren.
Tips voor het testen van eenheden
- Gebruik altijd een hulpmiddel of framework dat uw taal ondersteunt. Tools maken het eenvoudig om unit-testcases te ontwikkelen. Anders kunt u extra inspanningen leveren.
- Hoewel het voor alles wordt aanbevolen, is het soms handig om codes over te slaan die eenvoudig zijn en geen directe invloed hebben op het gedrag van het systeem. Getter- en settercodes kunnen bijvoorbeeld minder gericht zijn.
- Sla nooit codes over die direct van invloed zijn op het systeem of cruciaal zijn voor de implementatie van de bedrijfslogica.
- Gebruik testgegevens die lijken op productiegegevens.
- Isoleer uw code. Als uw code afhankelijk is van gegevens uit de database, schrijf dan geen testcase om de database aan te roepen en waarden op te halen. Maak in plaats daarvan een interface en bespot de API- en database-aanroepen.
- Voordat u een bug oplost die voortvloeit uit het testen van de unit, schrijft u de testcase die het defect blootstelt. Daar zijn drie redenen voor:
- Je zult in staat zijn om de regressiefouten die uit je fix voortvloeien op te vangen.
- Uw testcase is nu uitgebreider.
- Vaak is een ontwikkelaar te lui om zijn testgevallen bij te werken nadat deze zijn geschreven.
- Naast het schrijven van testcases die de bedrijfslogica verifiëren, schrijf je ook cases die de prestaties van je code testen. Met name wanneer codes betrekking hebben op lussen, zijn de prestaties het meest getroffen gebied.
Dingen om te onthouden
- Eenheidstestgevallen moeten onafhankelijk zijn van
- De te testen code - Elke wijziging in de code hoeft geen wijziging in de testcase van de unit te vereisen, tenzij de bedrijfslogica zelf verandert. Als de logica nu bijvoorbeeld vereist dat een geldig telefoonnummer altijd met '+' begint, moet de testcase van de unit worden gewijzigd, anders niet.
- De andere code - Er mag geen interactie of afhankelijkheid zijn met een ander stuk code of database-waarde of iets dergelijks. Een eenheid moet tijdens de test worden geïsoleerd.
- Volg duidelijke en consistente naamconventies voor uw testgevallen. Het maakt het eenvoudiger om de scenario's te volgen. U kunt ook versiebeheerprogramma's gebruiken om uw testgevallen bij te houden.
- Geef uw code nooit door aan de volgende fase totdat deze is voltooid, bugs zijn opgelost en opnieuw zijn getest.
- Het belangrijkste is om er een gewoonte van te maken. Dit is een coderingspraktijk die moet worden ingeprent. Hoe meer u codeert zonder eenheidstests, hoe meer foutgevoelig uw code is.
Carrière in het testen van eenheden
Hoewel het testen van eenheden geen geheel veld is, is het toch een extra pijl in je pijlkoker. Het is een goede codeerpraktijk en wanneer hebben goede codeerders niet de voorkeur?
Conclusie
Er kan onbetwist worden geconcludeerd dat het testen van eenheden soms eenvoudig en op andere complexe momenten kan zijn. Dat is wanneer de tools en frameworks u te hulp komen. Zelfs als de unit is getest, is de code niet volledig foutbestendig. Dat is het moment waarop de testprocedures van het volgende niveau van start gaan. Van al deze onzekerheden is het enige dat zeker is dat eenheidscontrole noodzakelijk is.
Aanbevolen artikelen
Dit is een handleiding voor het testen van eenheden. Hier bespraken we het belang, tips, tools, carrière en soorten unit testing met zijn voorbeelden. U kunt ook onze andere voorgestelde artikelen doornemen voor meer informatie -
- Interviewvragen testen
- Webtesttoepassing
- Defecte levenscyclus bij het testen van software
- Carrières in het testen van software
- Lijst met testkaders voor Java