How Guru’s Engineers Use Cypress for Better Burn Testing
Een betere manier nodig om burn-testing aan te pakken? Twee van onze front-end engineers hebben een manier gevonden om Cypress te gebruiken om de manier waarop ze QA uitvoeren te verbeteren.
Wij delen graag kennis bij Guru, en wanneer we iets nieuws en nuttigs ontdekken, willen we dat de wereld het weet! Ons engineeringteam gebruikt Cypress in hun test- en QA-proces. Ze hebben een nieuwe manier ontdekt om betere burn-tests uit te voeren, en ze willen hun nieuwe en verbeterde proces delen met andere engineers en testers.
In het afgelopen jaar hebben we ons gericht op het vergroten van onze testdekking — specifiek end-to-end testen die ervoor zorgt dat verschillende delen van onze productstromen correct functioneren wanneer we code-updates aanbrengen. Voor dit soort testen maken we gebruik van een tool genaamd Cypress, die het gebruikersgedrag met onze webapp en Google Chrome-extensie simuleert. Deze testsuite draait bij elke pull-aanvraag om ervoor te zorgen dat nieuwe code geen problemen veroorzaakt in onze UI. We willen ook voorkomen dat releases worden uitgebracht als onze Cypress-suite faalt op onze productiebranch.
Wat we zoeken in traditionele testing
Een probleem waar we mee te maken hebben gehad, is dat enkele van onze tests falen, maar niet om redenen die verband houden met de UI of code. Dus, hoe helpt Cypress ons in deze gevallen? We laten Cypress optreden als een gebruiker wiens gedrag we kunnen definiëren. Er zijn verschillende factoren die kunnen leiden tot Cypress die ons vertelt dat er een storing is, maar vanuit het perspectief van een gebruiker lijkt er niets mis.
Bijvoorbeeld, er kan een test zijn die zegt: “Ga naar dit gedeelte van de webapp > Voeg een nieuwe Guru-kaart toe > Verwacht een status na creatie te zien”. Als de laadtoestand van het aanmaken van een kaart een milliseconde te lang aanhoudt en Cypress begint te zoeken naar de status na creatie voordat deze daar is, kan deze test falen (meestal zal deze test echter slagen). Als het eenmaal slaagt bij een pull-aanvraag, kunnen we code samenvoegen die soms onbetrouwbaar kan zijn. Maar we zullen niet weten of dat zo is; een geslaagde test is geen garantie dat de code correct is.
Dit soort situaties verlaagt de betrouwbaarheid van onze testdekking. Als resultaat, wanneer een testfout opduikt in onze implementatiepipeline, moeten we verifiëren of het probleem bij de UI ligt - of bij de test. Om dit op te lossen, zijn we gaan nadenken over manieren waarop we kunnen detecteren of een test mogelijk onbetrouwbaar is voordat deze naar onze productiecodebranch gaat.
Hoe burn-testing helpt
Burn-testing introduceren. Burn-testing is een proces dat wordt gebruikt om iets onder meer rigoureuze of extreme omstandigheden te testen. Het wordt ook soms stress-testing of load-testing genoemd, afhankelijk van de methode of specifieke gebied dat wordt getest.
Bij Guru gebruiken we burn-testing als onderdeel van onze Cypress-suite voor nieuwe of aangepaste tests die aan onze codebase worden toegevoegd. Voordat deze tests kunnen worden samengevoegd, voeren we ze meerdere keren achter elkaar uit en ze moeten allemaal slagen om door te kunnen gaan naar de volgende stap in onze CircleCI-bouwpipeline.
Deze stap vindt onmiddellijk plaats voordat we de hele Cypress-testsuite uitvoeren. Het voordeel van deze volgorde is dat als onze burn-teststap een fout produceert, we de hele controle vroeg als een fout kunnen markeren. Het overslaan van de rest van de suite stelt ons in staat tijd te besparen en het aantal cycli te verminderen dat nodig is om ervoor te zorgen dat nieuw geïntroduceerde tests zo betrouwbaar en fouttolerant zijn als we nodig hebben.
Om de bestanden te vinden waar we naar op zoek zijn, gebruiken we git diff op de huidige branch en geven we de uitvoer door als parameter aan een tool genaamd cypress-repeat die ons in staat stelt om die tests een opgegeven aantal keren uit te voeren, waarmee burn-testing effectief als een stap in onze end-to-end testruimte wordt toegevoegd.
Het resultaat
Deze aanpassing aan onze testplannen heeft enkele behoorlijk positieve resultaten opgeleverd. Voor ons kan het toevoegen van burn-testing de tijd die nodig is om onbetrouwbare tests te vinden met maximaal 30 minuten verminderen. Het verbetert ook de doorlooptijd voor het toevoegen van nieuwe functionaliteit. Aangezien de nieuw toegevoegde tests nu als eerste worden uitgevoerd, kunnen ze ons helpen om de stabiliteit te verifiëren voordat we doorgaan naar de rest van het bouwproces.
Over het algemeen verhoogt onze voortdurende focus op het efficiënter en robuuster maken van onze testprocessen het vertrouwen van het hele engineeringteam in het snel uitbrengen van nieuwe functies. We lossen bugs sneller op en maken het gemakkelijker om over al onze codebases heen te werken. We hopen dat deze post andere Cypress-gebruikers helpt om betere tests te maken en teams efficiënter te laten bouwen.
Wij delen graag kennis bij Guru, en wanneer we iets nieuws en nuttigs ontdekken, willen we dat de wereld het weet! Ons engineeringteam gebruikt Cypress in hun test- en QA-proces. Ze hebben een nieuwe manier ontdekt om betere burn-tests uit te voeren, en ze willen hun nieuwe en verbeterde proces delen met andere engineers en testers.
In het afgelopen jaar hebben we ons gericht op het vergroten van onze testdekking — specifiek end-to-end testen die ervoor zorgt dat verschillende delen van onze productstromen correct functioneren wanneer we code-updates aanbrengen. Voor dit soort testen maken we gebruik van een tool genaamd Cypress, die het gebruikersgedrag met onze webapp en Google Chrome-extensie simuleert. Deze testsuite draait bij elke pull-aanvraag om ervoor te zorgen dat nieuwe code geen problemen veroorzaakt in onze UI. We willen ook voorkomen dat releases worden uitgebracht als onze Cypress-suite faalt op onze productiebranch.
Wat we zoeken in traditionele testing
Een probleem waar we mee te maken hebben gehad, is dat enkele van onze tests falen, maar niet om redenen die verband houden met de UI of code. Dus, hoe helpt Cypress ons in deze gevallen? We laten Cypress optreden als een gebruiker wiens gedrag we kunnen definiëren. Er zijn verschillende factoren die kunnen leiden tot Cypress die ons vertelt dat er een storing is, maar vanuit het perspectief van een gebruiker lijkt er niets mis.
Bijvoorbeeld, er kan een test zijn die zegt: “Ga naar dit gedeelte van de webapp > Voeg een nieuwe Guru-kaart toe > Verwacht een status na creatie te zien”. Als de laadtoestand van het aanmaken van een kaart een milliseconde te lang aanhoudt en Cypress begint te zoeken naar de status na creatie voordat deze daar is, kan deze test falen (meestal zal deze test echter slagen). Als het eenmaal slaagt bij een pull-aanvraag, kunnen we code samenvoegen die soms onbetrouwbaar kan zijn. Maar we zullen niet weten of dat zo is; een geslaagde test is geen garantie dat de code correct is.
Dit soort situaties verlaagt de betrouwbaarheid van onze testdekking. Als resultaat, wanneer een testfout opduikt in onze implementatiepipeline, moeten we verifiëren of het probleem bij de UI ligt - of bij de test. Om dit op te lossen, zijn we gaan nadenken over manieren waarop we kunnen detecteren of een test mogelijk onbetrouwbaar is voordat deze naar onze productiecodebranch gaat.
Hoe burn-testing helpt
Burn-testing introduceren. Burn-testing is een proces dat wordt gebruikt om iets onder meer rigoureuze of extreme omstandigheden te testen. Het wordt ook soms stress-testing of load-testing genoemd, afhankelijk van de methode of specifieke gebied dat wordt getest.
Bij Guru gebruiken we burn-testing als onderdeel van onze Cypress-suite voor nieuwe of aangepaste tests die aan onze codebase worden toegevoegd. Voordat deze tests kunnen worden samengevoegd, voeren we ze meerdere keren achter elkaar uit en ze moeten allemaal slagen om door te kunnen gaan naar de volgende stap in onze CircleCI-bouwpipeline.
Deze stap vindt onmiddellijk plaats voordat we de hele Cypress-testsuite uitvoeren. Het voordeel van deze volgorde is dat als onze burn-teststap een fout produceert, we de hele controle vroeg als een fout kunnen markeren. Het overslaan van de rest van de suite stelt ons in staat tijd te besparen en het aantal cycli te verminderen dat nodig is om ervoor te zorgen dat nieuw geïntroduceerde tests zo betrouwbaar en fouttolerant zijn als we nodig hebben.
Om de bestanden te vinden waar we naar op zoek zijn, gebruiken we git diff op de huidige branch en geven we de uitvoer door als parameter aan een tool genaamd cypress-repeat die ons in staat stelt om die tests een opgegeven aantal keren uit te voeren, waarmee burn-testing effectief als een stap in onze end-to-end testruimte wordt toegevoegd.
Het resultaat
Deze aanpassing aan onze testplannen heeft enkele behoorlijk positieve resultaten opgeleverd. Voor ons kan het toevoegen van burn-testing de tijd die nodig is om onbetrouwbare tests te vinden met maximaal 30 minuten verminderen. Het verbetert ook de doorlooptijd voor het toevoegen van nieuwe functionaliteit. Aangezien de nieuw toegevoegde tests nu als eerste worden uitgevoerd, kunnen ze ons helpen om de stabiliteit te verifiëren voordat we doorgaan naar de rest van het bouwproces.
Over het algemeen verhoogt onze voortdurende focus op het efficiënter en robuuster maken van onze testprocessen het vertrouwen van het hele engineeringteam in het snel uitbrengen van nieuwe functies. We lossen bugs sneller op en maken het gemakkelijker om over al onze codebases heen te werken. We hopen dat deze post andere Cypress-gebruikers helpt om betere tests te maken en teams efficiënter te laten bouwen.
Ervaar de kracht van het Guru-platform uit de eerste hand - maak onze interactieve producttour
