Innan man kan börja skriva tester i Cypress bör man förstå hur verktyget är uppbyggt. Strukturen definierar hela arkitekturen och jobbflödet vilket underlättar arbetet i verktyget. De flesta testverktyg (som Selenium) använder nätverket för att skicka sina anrop till webbläsaren via en så kallad Driver vilket enkelt kan förklaras med att testerna körs utanför webbläsaren.
Metoden gör det svårt för oss att förstå hur webbläsaren kommer att bete sig vid varje anrop. Om vi antar att vi skickar ett anrop som ska klicka på en knapp i webbläsaren och sedan verifiera resultatet vid nästa anrop. Om API responsen då skulle ta några sekunder från att du tryckte på knappen tills att resultatet är synligt i webbläsaren kommer Selenium inte att vänta med att skicka nästa anrop (verifieringsanropet), om du inte specifikt programmerar en Wait funktion. När nästa anrop väl skickas har inte webbläsaren hunnit ladda fram resultatet och steget misslyckas.
Du kan lägga Waits/Sleeps överallt i koden men de kommer bara att resultera i långsamma exekveringar i längden.
Cypress är raka motsatsen där alla anrop sker direkt i webbläsaren, med andra ord kan man säga att det är webbläsaren som exekverar testerna. Det gör det möjligt för Cypress att lyssna och ändra webbläsarens beteende under exekveringen genom att manipulera DOM (Document Object Model) strukturen och ändra närverksförfrågningar och svar i farten. Som exemplet ovan kommer Cypress att automatiskt vänta med att skicka nästa anrop tills API responsen är klar.
Metoden har givetvis begränsningar och nackdelar, eftersom det körs i webbläsaren finns det inget stöd för flera webbläsarflikar eller popup-fönster. Man kan heller inte använda Cypress för att köra två webbläsar instanser samtidigt.
Sist gick vi igenom hur du kommer igång med verktyget och i detta inlägg tittar vi närmare på strukturen.
Första gången man startar Cypress skapas det en mapp struktur enligt bilden nedan:
1. Cypress är mappen som kommer att innehålla all nödvändig information angående dina tester.
Mappen har i sin tur några underliggande mappar som vi kommer att titta närmare på:
Fixtures: används för att spara statiskt testdata för dina tester i form av en JSON data fil, här kan man spara till exempel inloggningsuppgifter. Cypress läser av automatiskt denna mapp för att extrahera testdatat vid körningen.
Integration: här kommer dina testfall att ligga. Mappen innehåller också dem "exempel” testerna som kommer vid installationen av Cypress.
Plugins: här kan man använda sig av olika Plugins för att kunna utöka Cypress funktionalitet eller ändra Cypress beteendet. Ett exempel är att kunna ändra namnet på en skärmdump som tas vid en misslyckad testkörning.
Support: mappen används för att placera återanvändbart kod som kan behövas vid flera testfall och på så sätt slippa ha repetitiv kod.
2. Node_Modules innehåller alla bibliotek och filer som krävs för projektet.
3. Cypress.json används för att lagra olika konfigurationer, till exempel timeout, bas URL:en och olika miljökonfigurationer.
För varje testautomatiseringsverktyg är Test Runner en viktig del av verktyget. Anledningen är att den ger en startpunkt för exekveringen av testfallen. Cypress har en unik Test Runner med några nyckelfunktioner som separerar den från dem andra verktygen:
Exekveringen i realtid.
Andra testverktyg kör testerna i realtid också men till skillnad från resten så visar Cypress alla dina teststeg under exekveringen och på så sätt har du full kontroll över exekveringen, och om ett teststeg går fel, kan man enkelt navigera tillbaka till koden och börja undersöka.
Testresultat.
Man får en exekveringsöversikt när exekveringen är klar med antal godkända tester, misslyckade och körningstiden.
Gå back i tiden.
Navigera mellan teststegen för att reda ut exakt vad som hände, detta låter dig se hur applikationen var före och efter test stegen utfördes. Man kan också granska konsol loggar och nätverksanrop.
Identifiera objekt.
Cypress hjälper oss att enkelt lokalisera webb-element för att sedan kunna anropa det specifika objektet i koden.
Att exekvera testerna i gränssnittet är optimalt under utvecklingsprocessen av testfallet, man kan se exakt hur testfallet beter sig under exekveringen samt kunna felsöka enkelt vid eventuella problem. När man är klar med utvecklingsprocessen kommer man vilja ha exekveringen utan interaktion med gränssnittet (i headless mode), för att kunna möjliggöra integrationen i en CI/CD (continuous integration/continuous delivery) verktyg.
Exekvering utan gränssnitt har sina fördelar i form av snabbare körningar samt möjligheten att starta en körning när som helst under dygnet. Och med det sagt är man nu redo att skriva sitt första testfall med Cypress. Till nästa gång kommer vi titta på mer tekniska aspekter samt skriva vårt första testfall.