Wist je dat Tricentis Tosca….CI/CD integratie nog makkelijker h

Wederom welkom terug! Op het moment van schrijven van dit artikel heeft Tricentis een patch 4 uitgebracht voor de Tosca Test Suite en een patch 3 voor de Tosca Server (beiden versie 15.2 LTS), overigens geen noemenswaardige veranderingen of verbeteringen t.a.v. de Tosca Execution Client en de Tosca Server Execution API. In mijn vorige blog deel 1(externe link)  heb ik laten zien hoe je het eerste stukje “CI” succesvol kan realiseren. In deze blog gaan we verder met het gebruik van CI tool Jenkins, om deze vervolgens te configureren met een bestaande GitHub repository. Het gaat om Javascript-code dat we verder bewerken of ontwikkelen in bijvoorbeeld Visual Studio Code (IDE). Hierover later meer bij de configuratie-stappen. Laten we eerst even een stapje terug doen met wat belangrijke test nieuws!

Zoals je weet is Tricentis intussen zeer actief geweest rondom ontwikkelingen op het gebied van testen in de cloud, denk aan Elastic Execution Grid, overigens nog steeds een tech preview. Maar interessanter om te benoemen is dat Tricentis per 1 maart 2023 stopt met de support en het verder ontwikkelen van TestProject(externe link), een opensource cloud test platform. Eerder al benoemd in 1 van mijn Tosca blogs. Voor veel “opensource liefhebbers” zal dit een bittere pil zijn, vooral omdat TestProject (met Selenium onder de motorkap) zich heeft bewezen als betrouwbare, en niet onbelangrijk om te vermelden, een “community driven” test framework met wereldwijde support. Wat is dan het alternatief? Volgens Tricentis wordt de volledige focus gelegd op Testim(externe link), een SaaS-gebaseerde en AI-aangedreven testautomatiseringstool voor “op maat gemaakte” web-applicaties. Toch bood TestProject ook (gratis) “on premise” mogelijkheden met de (lokale) TestProject server, vooral goed voor organisaties die (data) security, controle en eigen beheer hoog in het vaandel hebben. Het vermoeden bestaat dat Elastic Execution Grid deze rol gedeeltelijk zal overnemen als standaard feature binnen toekomstige versies van Tosca (versie 16?). Last but not least, een belangrijke mededeling voor de “die hard” Jenkins en Tosca fans, die de Tricentis Jenkins plugin(externe link) gebruiken; Betreffende plugin is vanaf Tosca versie 15.2 niet meer geschikt, en wordt overigens al 3 jaar lang niet meer ge-update, waardoor de kans groot is op kwetsbaarheden. De Tosca Execution Client makes your life easier! En nu weer terug naar de configuratie!

DEX en Tosca Execution Client configureren in Jenkins

Wat hebben we nodig om het 2^de gedeelte succesvol te realiseren? Het 1^ste gedeelte (met de DEX-server in de hoofdrol) is als het goed is succesvol gerealiseerd (check hiervoor deel 1(externe link)). Verder is een gezonde dosis verstand, een CI-tool, een IDE-tool en een cloud repository voor nu voldoende. Voor de CI-tool gaan we dit keer Jenkins gebruiken, en deze gaan we configureren met een GitHub repository. Visual Studio Code gebruiken we voor het bewerken van Javascript-code om een “trigger”, een check-in, te realiseren voor het uitvoeren van een CI-pipeline. Voor degene die niet weten hoe Jenkins te installeren, verwijs ik naar de website van Jenkins (zie link helemaal onderaan). Uiteraard is het verder belangrijk dat je ook een geldige GitHub-account hebt (zie ook link helemaal onderaan), mocht je de code zelf willen bewerken en updaten. Nadat de (lokale) Jenkins-server is opgestart, maken we in het kader van project-structuur een Jenkins project-map aan, zoals in figuur 1 is weergegeven. Het gaat om de map met de naam “Component Testen”. Component Test is hierbij bewust gekozen, vanwege de testsoort, aangezien er een frontend test moet worden uitgevoerd op een React-applicatie, vanwege een code-wijziging.

Figuur 1. Jenkins-dashboard / “Component Testen” map

In diezelfde map maken we vervolgens een Jenkins-job aan met de naam “Component Test” (zie figuur 1). De bedoeling is dat Jenkins de testuitvoer van de Tosca TestEvents gaat regelen. Maar hoe stel je dit in zonder de welbekende “Tosca CI”(externe link)? Dat kan heel eenvoudig met de Tosca Execution Client (TEC)! Voordat we de Jenkins-job verder gaan configureren, eerst even een korte beschrijving van de “pipeline” test scenario. Het gaat hier om een component test dat door Tosca moet worden uitgevoerd naar aanleiding van een code-wijziging (check-in) in de front-end, een React web-applicatie, onderhouden in een GitHub-repository. In de Tosca-workspace hebben we hiervoor een TestEvent voorbereid (zie deel 1(externe link)).

Om het testproces verder overzichtelijk te houden, maken we eerst lokaal een “component test” map aan, zie figuur 2.

 Figuur 2. Lokale “component test” map

In de “component test” map maken we een kopie van het “tosca_execution_client.ps1” bestand en veranderen de naam in “component_test”. De bedoeling is dat we de component testresultaten en logs in een aparte map opslaan en onderhouden. Bovendien is dit veel overzichtelijker en we hoeven het originele “tosca_execution_client.ps1” bestand dan niet te wijzigen. De inhoud van de map ziet er dan als volgt uit (zie figuur 3).

Figuur 3. Inhoud map “component test”

Vervolgens gaan we “hardcoded” parameter wijzigingen aanbrengen in het “component_test” powershell-script. Je kan hier bijvoorbeeld de gebruiksvriendelijke Notepad++ voor gebruiken of als lokale test project toevoegen in een IDE, zoals Visual Studio Code. Om het simpel te houden, gebruiken we voor nu even Notepad++ (zie figuur 4).

Figuur 4. Hardcoded parameters

Het gaat om de volgende parameters:

• $toscaServerUrl
• $projectName
• $events

Waarom de parameters in kwestie “hardcoded” toevoegen? Omdat dit om 1 specifieke test gaat, en vooral voor “simplificatie” bij het configureren in Jenkins. Uiteraard zal dit in de praktijk net ietsjes anders zijn. Sla de wijzigingen op en keer terug naar Jenkins!

In Jenkins hoeven we alleen nog maar een build-stap toe te voegen en deze te configureren voor testuitvoer m.b.v. de Tosca Execution Client. In figuur 5 wordt dit goed weergegeven.

Figuur 5. Jenkins build-stap

Sla de configuratie-wijzigingen voor de Jenkins-job op en controleer middels een dry-run, door build “Component Test” uit te voeren, of dit stukje “build proces” goed loopt. Als alles succesvol is uitgevoerd, worden in de lokale sub-map “component test” 2 extra sub-mappen aangemaakt, te weten “logs” en “results”. Dit zijn inclusief de testresultaat-bestanden (zie figuur 6).

Figuur 6. Lokale mappen “logs” en “results”

Let’s go on GitHub!

Het stukje Jenkins is nu bijna volledig ingericht, en de volgende stap is de koppeling met GitHub! We gebruiken een bestaande GitHub-repository, uiteraard kun je ook een andere repository kiezen. Vul vervolgens nog de volgende gegevens aan in Jenkins, te weten, “Repository URL” en “Poll SCM” (zie figuren 7 en 8).

Figuur 7. Repository URL

Figuur 8. Poll SCM

Optie “Poll SCM” wordt gebruikt om “periodiek” de GitHub-repository te controleren op updates. In bovenstaande situatie wordt dit per minuut gedaan. Afhankelijk van de performance of release-planning van de (OTA-)omgeving en de bijbehorende infrastructuur kun je als organisatie besluiten om dit per uur of bijvoorbeeld per dag te doen. Als we de bovenstaande gegevens vervolgens opslaan, dan is hiermee de volledige “CI” configuratie m.b.v. de Tosca Execution Client bewerkstelligd. Lekker eenvoudig toch?

What’s next? De Tosca Server Execution API?

Het stukje “Tosca Execution Client” (TEC) configuratie is nu succesvol afgerond. Zijn er andere mogelijkheden om te communiceren met de DEX-server in een CI/CD proces? Het alternatief voor TEC, of beter gezegd het complement, is de zogenaamde “Tosca Server Execution API”. Met de “Execution API” van de Tosca Server, krijg je wat meer flexibiliteit in je CI-pipeline. De integratie van CI-pipeline en Tosca werkt met de Tosca Server Execution API i.c.m. TestEvents, maar dan op “service” niveau.

Als je als Tosca Test Engineer eerst dingen wilt uitproberen rondom API’s, dan kan dat op een eenvoudige manier. De (Tosca Server) API-structuur wordt middels een zogenaamde Swagger-definitie weergeven (in mijn geval):

http://localhost:81/automationobjectservice/swagger/index.html(externe link)

Bovenstaande URL bestaat uit 2 delen, het eerste stukje is de Tosca Server URL, en de toevoeging “/automationobjectservice/swagger/index.html” verwijst naar de Swagger-definitie.

Alvast meer weten over “Tosca Server Execution API”? Meer informatie vind je hieronder of volg mijn blogs!

Verder groeien in Tosca?

Nu kun je jezelf rekenen tot een select gezelschap van DevOps-gildes! Gaaf toch? Wil jij iedere dag leren en kunnen sparren met vakgenoten over bijvoorbeeld Tosca of andere testautomationtoolings? Neem gerust contact op, ik vertel je er graag meer over. Benieuwd naar mijn volgende artikel (5^de in de reeks)? Voor nu even een zomerstop. In de tussentijd, bekijk gerust de vacatures en wie weet, misschien worden we wel collega’s.

Tosca Test vacatures

Testspecialisten

Als testen niet alleen je vak maar ook je passie is, ontdek dan onze testcommunity!

Naar Testen