Introductie

Anno 2022 zijn er veel verschillende test automation frameworks en tools beschikbaar. Als QA engineer moet je altijd nagaan welke tool of framework het doel dient. Veel van deze test automation frameworks en tools hebben Selenium als fundering. Cypress is een test automation framework dat anders is. Daarnaast stijgt de populariteit van Cypress al jaren [5] en biedt het ontzettend veel mogelijkheden. Bij codecentric zien we dat kennis over en ervaring met dit framework steeds vaker gevraagd wordt in de markt.
In deze blog ga ik in op wat Cypress zo uniek maakt door in te gaan op de features die wat mij betreft het meest waardevol zijn ten opzichte van de concurrentie.

Cypress versus Selenium

Cypress wordt vaak vergeleken met Selenium, waarschijnlijk omdat die laatste bekender is. Selenium bestaat namelijk sinds 2004 en was de eerste tool die het mogelijk maakte om de handelingen in browser te automatiseren [4]. De eerste release van Cypress was in april 2015 en heeft vanaf dat moment steeds meer marktaandeel veroverd [5]. Buiten het feit dat Cypress nieuwer is dan Selenium, verschillen ze ook in de functionaliteiten en architectuur. Het belangrijkste verschil is dat Cypress in de browser draait en Selenium een browser simuleert via een WebDriver. Het voordeel dat Cypress in de browser draait is dat de webapplicatie in dezelfde omgeving getest kan worden als waarin de gebruikers werken.

Waarom Cypress?

Cypress heeft veel voordelen. Het is vrij beschikbaar (open source), makkelijk te installeren en Cypress kan de hele testpiramide afdekken [1]. Zowel end-to-end-testen, integratietesten als unittesten.

Cypress & de testpiramide

Cypress is een end-to-end JavaScript testing framework dat gefocust is op het testen van de UI. Dat betekent dat Cypress aan de bovenkant van de testpiramide (zie afbeelding hieronder) zit, de end-to-end-testen. Echter, heeft Cypress de mogelijkheid om ook de overige lagen af te dekken en dat is meteen de kracht van deze tool.

We maken even een klein sprongetje naar de theorie. De testpiramide, hoe zat het ook alweer? De onderste laag bestaat uit de unittesten. Dit zijn de testen op de kleinste schaal die direct aansluiten op de broncode. Omdat issues goedkoper zijn om op te lossen in de ontwikkelfase en omdat hier de meeste bugs voorkomen, zijn er van deze testvorm de meeste en vormt dit de basis van de testpiramide.

Hierna volgt de integratielaag, hier wordt gevalideerd hoe de verschillende componenten op elkaar aansluiten. Hoe hoger in de piramide hoe minder testactiviteiten er nodig zijn.

Bovenaan de piramide staan de end-to-end--testen. Dit zijn geen deeltesten meer maar hier wordt de hele applicatie getest van front-end naar back-end. Test automation tools zitten in deze laag omdat deze gebruik maken van de front-end. Het doel hiervan is om gebruikersgedrag te simuleren. Het nadeel van end-to-end-testen is dat hier de meeste complexiteit zit en de testen kwetsbaar zijn omdat de schakels in de keten van elkaar afhankelijk zijn. Zo kan één wijziging in de UI (of ergens anders in de keten) meerdere testen breken [2]. Het voordeel dat Cypress eerder ingezet kan worden in het ontwikkelproces zorgt ervoor dat je minder tijd kwijt bent aan het testen wat het project goedkoper maakt. Zo ondersteunt het een gezonde testpiramide.

Nu hoor ik je denken; “hoe ziet dit er dan in de praktijk uit, hoe kun je nou een unittest uitvoeren in Cypress?” Ontwikkelaars schrijven toch altijd de unittesten!
Nou nee, In de linker afbeelding hieronder, staat als voorbeeld een rekenfunctie. In de rechter afbeelding staat een aantal testen dat checkt of de vier rekenfuncties doen wat verwacht wordt dat ze doen.

Zoals in de afbeelding hieronder is te zien, zijn de testen allemaal succesvol uitgevoerd waarbij er geen UI aan te pas is gekomen.

Nu duidelijk is wat de verschillen zijn tussen Selenium en Cypress en waar Cypress zich bevindt in de testpiramide. Ga ik enkele features van Cypress toelichten, leg ik uit hoe je ze kunt gebruiken en wat je eraan hebt.

Cypress key features

Feature 1: Realtime reloads

Als testautomatiseerder herken je het vast wel, de test die je hebt gemaakt, loopt halverwege stuk. Bijvoorbeeld doordat een bepaald webelement niet gevonden wordt. Je maakt een aanpassing in de test en moet daarna weer dat ene commando runnen om te controleren of de test nu wel slaagt. Cypress heeft hier wat op bedacht en dat is wat mij betreft een waardevolle functionaliteit namelijk, “realtime reloads”. Dit betekent dat elke keer dat een testbestand, bijvoorbeeld (xyz_spec.js) wordt opgeslagen, Cypress automatisch een nieuwe testuitvoering doet. Het activeert dus automatisch een nieuwe run zodra het bestand wordt opgeslagen. Het is dus niet meer nodig om de run handmatig te activeren tijdens het ontwikkelen van je test.

Feature 2: Time traveling

Het debuggen van applicaties om fouten voortijdig op te lossen wordt al jaren gedaan en is een belangrijk onderdeel voor het ontwikkelen van goede software. Time traveling is in Cypress onderdeel van het debuggen. Het houdt in dat je door de verschillende gedefinieerde stappen in de testcase kan navigeren door op elke stap te klikken.

In de onderstaande afbeelding staan de stappen beschreven die Cypress heeft uitgevoerd tijdens een testrun.

Afbeelding 1: In de bovenstaande afbeelding staan de testuitvoerstappen. Cypress brengt de testuitvoer onder in verschillende stappen. In bovenstaande afbeelding is testuitvoer stap 5 gemarkeerd. Op het moment dat de stap gemarkeerd is, kan je in de browser waar de testrun draait, zien of het juiste webelement gevonden is. Bekijk hiervoor afbeelding 2.

Afbeelding 2: In deze afbeelding zie je in de linker kolom testuitvoer stap 5 gehighlight. In de rechter kolom zie je de browser die de div “.products” highlight. Het juiste element is gevonden.

Afbeelding 3: In bovenstaande afbeelding zijn we nu naar testuitvoer stap 6 gegaan. Nu is niet meer de overkoepelende div “.products” gehighlight. Nu zijn de onderliggende divs “.product” gehighlight.

Afbeelding 4: Vervolgens gaan we nog een stapje verder, in stap 10 wordt er een assert gedaan met de check of dat de button de tekst “ADD TO CART” bevat, zo ja? Vervolgens wordt in stap 11 op de button geklikt en wordt het product toegevoegd aan de winkelwagen.
Time traveling zorgt er dus voor dat je als gebruiker door de verschillende “states” van de browser kan navigeren. Voor programmeurs is dit bekend, echter gebeurt dit dan niet in de browser, maar in de IDE van de programmeur tijdens het debuggen.

Feature 3: Cypress Task

Via de task-functie heb je de mogelijkheid om verschillende uitbreidingen te ontwikkelen die geen browser vereisen. De Cypress-task-functionaliteit kan je bijvoorbeeld inzetten voor het vullen van een database met testdata.

In een vorige opdracht heb ik de kracht hiervan ervaren. Het was mijn taak om een Angular-applicatie geautomatiseerd te testen waarbij de authenticatie was geregeld via Azure AD. De manier van inloggen zou ook in productie zo blijven. Na wat onderzoek bleek dat het inloggen in Azure AD niet te automatiseren was met de standaard functionaliteit in Cypress, maar het inloggen moest wel getest worden.
Ik heb een geautomatiseerde testcase gemaakt in Cypress waarbij vooraf werd ingelogd in Azure AD. Vervolgens heb ik het inlogproces geautomatiseerd met Puppeteer. Dit is een headless Chrome Node JS API, die ik had toegevoegd aan het Cypress-project. De JavaScript code voor het inloggen in Azure AD met Puppeteer kon vervolgens geïntegreerd worden in de testcase in Cypress. Dit zorgde voor een goede afhandeling van het inloggen in Azure AD, om vervolgens de rest van de testcase te automatiseren in Cypress.

Cypress biedt uiteraard nog veel meer mogelijkheden. Ben je benieuwd of Cypress je kan ondersteunen in het testautomatiseringsproces? Of wil je meer weten hoe je bovenstaande functionaliteit kan toepassen in jouw project?

Neem dan contact op via daniel.vanbavel@codecentric.nl

[1] https://docs.cypress.io/guides/overview/why-cypress#Who-uses-Cypress
[2] https://en.wikipedia.org/wiki/Test_automation#Testing_at_different_levels
[3] https://learn.cypress.io/testing-foundations/the-testing-pyramid
[4] https://www.selenium.dev/history/
[5] https://2021.stateofjs.com/en-US/libraries/testing/