Share
Dit is een uittreksel uit het Unit Testing Beknopte eBook, door Marc Clifton, vriendelijk geleverd door Syncfusion.
De gebruikelijke mantra die we horen over elke softwaremethodologie is dat het de bruikbaarheid en kwaliteit verbetert, de ontwikkeling en testtijd verkort en het product sneller en met minder bugs op de markt brengt. Dit zijn verheven doelen, maar ik moet nog zien dat een methodologie de graal van softwareontwikkeling oplevert.
Uiteindelijk is de belangrijkste reden om eenheidstests te schrijven, om de juistheid te bewijzen, en dit gebeurt alleen als je eenheidstests schrijft goed. Eenheidstests alleen zullen de bruikbaarheid of kwaliteit van uw product niet direct verbeteren. Je kunt nog steeds een puinhoop maken van de applicatie, of deze nu correct is of niet, en het is zeker niet gegarandeerd dat dit de ontwikkeling en testtijd vermindert (hier later meer op) of breng je product eerder op de markt.
Laten we dus duidelijk en reëel zijn vanaf het begin: testen van eenheden kan worden gebruikt om de juistheid te controleren, en dergelijke bijwerking dat gebeurt met betrekking tot uw ontwikkelingsproces moet worden afgewogen tegen de inspanning van het schrijven en onderhouden van nuttige unit tests.
Goed geschreven eenheidsonderzoeken zullen u een meetbaar mate van vertrouwen dat de talloze methoden die uw applicatie omvat correct zullen werken. De eenvoudigste manier om deze meting objectief uit te voeren, is een dekkingstest: in welk percentage van de methoden in uw toepassing zijn er eenheidstests tegen geschreven? Hoewel deze vraag niet rechtstreeks behandelt of een methode als een eenheid moet worden beschouwd (later wordt besproken), of dat de tests zinvol zijn, is het toch een meting die u op elk moment kunt nemen en als maatstaf voor de juistheid van jouw toepassing.
Het testen van eenheden is een iteratief proces - er zullen altijd fouten zijn die worden gemist met het testen van eenheden. Het aantal gerapporteerde fouten in de loop van de tijd en het aantal onopgeloste en opgeloste problemen biedt echter zinvolle informatie over de gezondheid van uw toepassing. Hoewel het onmogelijk is om te zeggen: "Bij unit-testen is het aantal fouten met 50 procent verminderd", is het mogelijk om te meten hoeveel bugs uw applicatie heeft vanwege de onvolledige testdekking van de unit. Terwijl u eenheidstests schrijft om het probleem en de oplossing te verifiëren, kunt u ook meten hoeveel eenheidstests u hebt geschreven tegen gerapporteerde fouten in vergelijking met het totale aantal eenheidstests.
Al deze benchmarks brengen een zekere mate van objectiviteit naar uw ontwikkelingsproces. Daarom is een van de voordelen van unit testing dat iedereen, van ontwikkelaars tot managers, objectieve informatie krijgt die kan worden teruggekoppeld naar het ontwikkelingsproces om dat proces te verbeteren.
Een ander voordeel is herhaalbaarheid, ook wel regressietest genoemd. Naarmate een toepassing rijper wordt, willen we dat bestaande verzekeren, werkend code is niet verbroken. Door eenheidstests te schrijven tegen methoden terwijl ze worden geschreven en eenheidstests toe te voegen voor fouten terwijl ze worden gerapporteerd, kunnen deze allemaal automatisch opnieuw worden getest wanneer nieuwe code wordt toegevoegd of bestaande code wordt gewijzigd. Eenheidstests worden een aanzienlijk hulpmiddel voor het reduceren van de tijd als het gaat om het testen of een toepassing zich nog steeds correct gedraagt na een kleine of significante codewijziging. Hoewel het testen van eenheden niet in de plaats komt van het testen van bruikbaarheid, prestatietests, belastingtests, enzovoort, helpt het zeker om de tijd verspild aan de veelgestelde vraag te elimineren: "Dit werkte eerder; waarom is het niet nu? "
Het is eenvoudig om te testen of een methode het juiste doet wanneer alle processen in de methode lineair worden uitgevoerd. Echter, zodra u een toevoegen als verklaring of een schakelaar verklaring die je aan het maken bent cyclomatische complexiteit, wat een mooie manier is om te zeggen dat je code nu meerdere uitvoeringspaden heeft. De meest bruikbare eenheidstests zijn testen elke afzonderlijke codetak dat gebeurt in uw methode. Het schrijven van dit soort eenheidsonderzoeken kan nauwgezet zijn maar is de moeite waard, omdat ze garanderen dat ten minste elke codetak is uitgevoerd, wat niet kan gebeuren tijdens acceptatietesten, gebruikerstests of andere testen die de kwaliteitsborging afdeling (als je die hebt) presteert.
In deze serie gaan we een aantal verschillende strategieën en tips bekijken voor het uitvoeren van effectieve unit-testen.
Accentsconagua