{"id":21408,"date":"2021-08-27T10:54:51","date_gmt":"2021-08-27T08:54:51","guid":{"rendered":"https:\/\/www.software-developer-india.com\/wat-is-test-driven-development-of-td\/"},"modified":"2021-08-27T10:54:55","modified_gmt":"2021-08-27T08:54:55","slug":"wat-is-test-driven-development-of-td","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/nl\/wat-is-test-driven-development-of-td\/","title":{"rendered":"Wat is Test Driven Development? Of TD?"},"content":{"rendered":"\n

Wat is Test Driven Development? Of TD?<\/h2>\n\n
\"\"<\/a><\/figure><\/div>\n\n

Test Driven Development of TDD, zoals het in de ontwikkelaarskringen liefdevol wordt genoemd, is een belangrijk aspect van het softwareontwikkelingsproces. Door deze aanpak is het gemakkelijker om te testen wat een specifieke code zou doen. Er worden testcases gemaakt voor elke functionaliteit van de softwaretoepassing en wanneer een bepaalde functionaliteit faalt in een test, wordt de code herwerkt en worden er nieuwe codes gemaakt. De nieuwe code zou ook de test moeten doorstaan en vrij zijn van bugs. De ontwikkelaar hoeft alleen een nieuwe code te schrijven als de geautomatiseerde test voor de code is mislukt, dus er zal een testcase zijn voor elke functionaliteit, hoe klein ook. En bij TDD draait alles om het ontwerpen en ontwikkelen van tests voor elke afzonderlijke functionaliteit in de applicatie. <\/p>\n\n

De naam Test Driven Development geeft aan dat het proces van testen op de juiste manier de softwareontwikkeling aandrijft. Vandaar dat het proces zelf zijn wortels ontleent aan Agile-methodologie en Extreme-programmering. Dit proces zorgt ervoor dat ontwikkelaars code maken en onderhouden die veerkrachtig en langdurig is. <\/p>\n\n

Dus het proces voor TDD zou zijn om eerst de eenheidstest te schrijven, en als de test mislukt, dan de codewijzigingen door te voeren. Dit helpt ook bij het voorkomen van codeduplicatie. Het geheel draait op het schrijven en corrigeren van mislukte tests v\u00f3\u00f3r de daadwerkelijke ontwikkeling. Om de TDD echter succesvol te laten werken, is het raadzaam om de testgevallen naar eenvoudige testgevallen te schrijven. Voor complexe bedrijfslogica zou het erg moeilijk zijn om een combinatie van testcases te schrijven en volledig succes te behalen. Er is een kans dat je het schrijven van enkele tests mist, dus het is helemaal geen gemakkelijke taak. <\/p>\n\n

Verschil tussen TDD en traditioneel testen<\/strong><\/h3>\n\n

Traditioneel testen kost meer tijd dan TDD en is gebaseerd op de herhaling van een korte ontwikkelingscyclus. Eerst wordt de test vanaf het begin geschreven, daarna wordt de programmacode geschreven, gevolgd door het gewenste gedrag van het systeem. Wanneer de schriftelijke test is geslaagd (controleren van de juistheid van het werk van de ongeschreven code), wordt de geschreven code gerefactoreerd. <\/p>\n\n

In het begin zal TDD ook tijdrovend zijn, maar na verloop van tijd zal de ontwikkelaar eraan wennen omdat het ontwikkelingsproces meer gestructureerd zal worden. Wanneer u bijvoorbeeld een ontwikkelaar inhuurt, beslissen zij wat ze gaan schrijven en vervolgens hoe. <\/p>\n\n

Traditioneel testen is succesvol wanneer het een of meer defecten correct vindt. Net zo hetzelfde als TDD. Het vinden van defecten is eigenlijk een goed teken, want dan weet je dat je moet oplossen wat er mis is en van daaruit verder moet gaan. TDD geeft je ook meer vertrouwen wanneer je het programma vrijgeeft en zorgt ervoor dat het voldoet aan de vereisten waarvoor het is gedefinieerd. <\/p>\n\n

Bij traditioneel testen ligt de focus meer op het ontwerp van testcases, terwijl bij TDD de focus meer ligt op productiecode om te verifi\u00ebren of het testen volgens plan zal werken. <\/p>\n\n

TDD geeft u 100% testdekking, waarbij voor elke regel code wordt getest, dat is niet het geval bij traditioneel testen.<\/p>\n\n

Wanneer de projectomvang erg groot is, moet je echt grondig zijn tijdens het uitvoeren van de tests. En er is een kans dat het testen vertraging oploopt en het budget en de tijdsdruk overschrijdt. <\/p>\n\n

TDD is misschien moeilijk om te schrijven en het kan de ontwikkelingstijd vertragen, maar het zou op de lange termijn zeker zijn vruchten afwerpen. <\/p>\n\n

Een ander nadeel van TDD is dat het concept moeilijk toepasbaar is op bestaande legacy code. <\/p>\n\n

Het is altijd goed om de test te laten mislukken voordat je een project vrijgeeft, want dan weet je dat je een geldige test hebt uitgevoerd. Via TDD weet u dat uw systeem voldoet aan de eisen waarvoor het is ontworpen. De focus ligt dus meer op productiecode voor TDD, omdat dit ervoor zorgt dat het testen goed werkt. En wanneer de software voldoet aan alle gestelde eisen.<\/p>\n\n

De verschillende stadia van een testgedreven ontwikkeling<\/strong><\/h3>\n\n

Er zijn drie verschillende stadia van TDD: Rood, Groen en Refactor<\/p>\n\n

Volg deze volgorde van stappen om ervoor te zorgen dat u tests hebt voor de code die u schrijft, dus u hoeft de codes alleen te schrijven voor die tests die u doet. <\/p>\n\n

Het rode podium<\/strong><\/h3>\n\n

Het idee van de rode fase is om de test te laten mislukken, en de moeilijkste fase ook omdat de ontwikkeling een test moet schrijven zonder code. Nieuwe ontwikkelaars moeten het moeilijk vinden omdat ze in de war zouden raken over wat ze moeten testen zonder de code ervoor te hebben. Maar het is een gewoonte en met ervaring zal het soepel worden. De eerste test is geschreven zonder code te schrijven en om klasse en methode te declareren, en de test zal een compilatiefout hebben. De volgende stap zou zijn om de compilatiefout te herstellen en de test uit te voeren om deze te laten mislukken. Dit veroorzaakt de rode vlag.<\/p>\n\n

De groene fase<\/strong><\/h3>\n\n

Na de rode fase zou de volgende stap zijn om de code te schrijven. Deze code zal de eerste test moeten doorstaan. Gewoon voldoende code schrijven om ervoor te zorgen dat alleen de eerste test slaagt, is een hindernis waarmee veel ontwikkelaars in eerste instantie worden geconfronteerd. Omdat het bij de volgende test zou moeten mislukken, gevolgd door nieuwe code om ze te doorstaan. <\/p>\n\n

\"\"<\/a><\/figure><\/div>\n\n

De refractorfase<\/strong><\/h3>\n\n

In de eerste twee fasen, waarbij de test eerst moet falen en vervolgens moet slagen, was het doel om de tests vervolgens te laten slagen. Maar in de Refractor-fase moeten andere factoren worden overwogen, zoals de kwaliteit van de code, de onderhoudbaarheid van de code, de leesbaarheid van de code, enz. De focus ligt hier dus op die aspecten, dus de unittests zullen zich daarop richten. In de refactoringfase hoeft u zich geen zorgen te maken over het ontbreken van functionaliteit, want wanneer de codewijzigingen plaatsvinden, zullen de testgevallen automatisch ook voldoen aan het functionaliteitsgedeelte.<\/p>\n\n

TDD past goed in de Agile methodiek<\/strong><\/h3>\n\n

Het is vrij duidelijk dat projectvereisten tot ver in de ontwikkelingsfase kunnen veranderen, dus het hebben van TDD in samenwerking met Agile-ontwikkeling zal het zeker succesvol maken en projecten bouwen die zijn afgestemd op de vereisten van de klant. Met test-driven development krijg je eerder feedback op het project waar je makkelijk aan kunt werken. <\/p>\n\n

Het zou ook helpen anticiperen op en het verminderen van de kritieke knelpunten en ervoor zorgen dat het project verloopt zoals bedoeld. Ontwikkelaarsteams kunnen veel tijd besparen omdat de tests veel eerder in de projectontwikkeling worden gemaakt en ze zich geen zorgen hoeven te maken over uitgebreide testscripts. <\/p>\n\n

Conclusie<\/strong><\/h3>\n\n

Test Driven Development is een techniek die inderdaad tijdrovend is, maar het is waardevol in die zin dat het je project in de goede richting helpt sturen door correcte feedback over het project te krijgen en bugs te detecteren. Het is echter een veel betere optie dan traditioneel testen, omdat het meer tijd en geld kost. <\/p>\n\n

Interessante links:<\/p>\n\n

Test Driven Development: wat het is en wat het niet is.<\/a><\/p>\n\n

Meer informatie over Test-driven development<\/a><\/p>\n\n

Foto’s: Canvas<\/p>\n\n

\"\"<\/figure><\/div>\n\n

De auteur: Sascha Thattil werkt bij Software-Developer-India.com, een onderdeel van de YUHIRO Group. YUHIRO is een Duits-Indiase onderneming die programmeurs levert aan IT-bedrijven, agentschappen en IT-afdelingen.<\/p>\n