Veiliger voor de productie – Verhoog de productiviteit en testbetrouwbaarheid – Stelt u zich eens voor dat een nieuwe ontwikkelaar zich bij uw project voegt, en dat hij een job moet herwerken die door een ander teamlid is gemaakt, of die ene job die een tijdje geleden is gemaakt. Een scenario dat niet moeilijk voor te stellen is voor elke ETL ontwikkelaar. Nu, deze job voedt al een lange tijd een bepaald doelsysteem, maar we willen een nieuwe transformatie regel toevoegen of de job koppelen aan een nieuw of bijgewerkt bronsysteem.
Wat we niet willen is dat een ontwikkelaar alle stappen opnieuw moet doorlopen om een kleine wijziging aan te brengen. Maar zonder een goede beschrijving van het verwachte gedrag, is het moeilijk om de gewenste impact van de wijziging te verifiëren. De ontwikkelaar zou diep in de opdracht moeten graven om de functionaliteit en de geproduceerde resultaten te begrijpen. Dan – om de job te testen zou hij manueel de brongegevens en de doeloutput evalueren, kijkend naar zowel waarden als gegevenstypes, volgens de transformatieregels. Dit wordt een overbodige en tijdrovende taak – ongeacht hoe ervaren de ontwikkelaar is. Bovendien worden deze manuele controles waarschijnlijk uitgesteld tot het einde. En wanneer de testen handmatig zijn of visueel worden geïnspecteerd, neemt de kans op menselijke fouten bij het maken van testen & het valideren van de resultaten toe.
Test-Driven-Development
Laten we dit omdraaien en beginnen met Test-Driven-Development (TDD). Om dit te doen hebben we een zinvolle regressietest nodig die gemakkelijk kan worden begrepen en aangepast om de correcte werking van ons systeem onder verschillende scenario’s te valideren. Volgens deze aanpak zou de ontwikkelaar de jobcode en het testscript, die het verwachte gedrag beschrijven, naast elkaar bekijken. Als de verandering in de job een wijziging van het script vereist, wijzigt hij het testscript om het opnieuw aan de job aan te passen. Het script wordt hoe dan ook gebruikt om te begrijpen wat van de job wordt verwacht en om de functionaliteit van de job te valideren na de wijziging.
We gebruiken Robot framework om TDD in Talend te oefenen. Een flexibele keyword-gedreven aanpak om scripts voor testautomatisering te beschrijven en te implementeren. Een Robot Framework testsuite bestaat uit een of meer testscripts met sleutelwoorden en hun overeenkomstige argumenten. De eigenlijke tests worden leesbaar gehouden omdat hun complexiteit binnen de gebruikte testbibliotheken of resource bestanden is of zal worden gehouden. Dit maakt de eigenlijke scripts zeer overdraagbaar van de ene ontwikkelaar naar de andere en dient als documentatie van het verwachte gedrag. Een eerste inspanning moet worden geleverd om een generieke testsuite op te zetten. Maar als dat eenmaal is gedaan, zijn de bouwstenen, sleutelwoorden en zelfs script templates volledig herbruikbaar om nieuwe tests te definiëren.
Robot Framework gebruiken voor een generiek & geautomatiseerd testplatform
Robot Framework laat ons toe tests te definiëren die de werking van de verschillende componenten in ons ETL-systeem controleren, dus niet enkel job-intern. Als voorbeeld nemen we een sleutelwoord ‘Talend Job Succesvol Uitvoeren’ met de jobnaam als argument. Dit sleutelwoord is samengesteld uit andere bestaande sleutelwoorden gedefinieerd in gerefereerde test bibliotheken. Deze trefwoorden orkestreren dat de job op een externe opslag wordt benaderd, verwerkt en gecontroleerd op succesvolle voltooiing op basis van zijn retourcode. Een andere set sleutelwoorden controleert vervolgens of de juiste invoer is gemaakt in ons job management/audit framework, waarbij het gedrag van de job wordt gevalideerd in geval van happy of sad flows.
Onze testsuites, testgevallen en testgegevens worden gebouwd als een robot-maven testproject dat kan worden beheerd via Eclipse, niets ongemakkelijks hier voor een Talend ontwikkelaar. De tests kunnen dan getriggerd worden ofwel via de interface of via een Maven commando, wat de cruciale stap vormt om te integreren met en echte waarde te halen uit je Continuous Integration of Continuous Deployment pipeline.
Verhoog de productiviteit en testbetrouwbaarheid
Het gebruik van deze geautomatiseerde regressietests, in aanvulling op andere testfunctionaliteit die beschikbaar is in Talend, verhoogt de productiviteit van een ontwikkelaar en het vertrouwen in de gegevens. Zodra een testopzet is gedefinieerd, wordt de ontwikkelaar ontlast van het handmatig uitvoeren van de basis en repetitieve – maar essentiële – testtaken. En, nog belangrijker, het biedt een onmiddellijk en gedetailleerd feedback rapport, waardoor de ontwikkelaar snel het defect kan herstellen wanneer het herwerken nog vers in het geheugen ligt. Naast het handmatig triggeren van deze tests, kunnen ze ook worden getriggerd bij commit door een CI-server zoals Jenkins, om er zeker van te zijn dat alleen jobs die de tests hebben doorstaan, worden uitgerold.
In een van onze volgende nieuwsbrieven zullen we ons richten op de verschillende onderdelen van een CI/CD pijplijn voor data-integratie en kijken hoe testautomatisering daarin is verwerkt. Geïnteresseerd in meer informatie? Neem contact met ons op of neem een kijkje bij onze komende evenementen om ons persoonlijk te ontmoeten!