Een inleiding tot het testen van Frontend

Het testen van Frontend Code is nog steeds een verwarrende praktijk voor veel ontwikkelaars. Maar met Frontend-ontwikkeling steeds complexer en met ontwikkelaars die verantwoordelijk zijn voor stabiliteit en consistentie zoals nooit eerder, moeten frontend-testen worden omarmd als een gelijke burger in uw codebase. We breken je verschillende testopties af en leggen uit welke situaties waar ze het best voor kunnen worden gebruikt.

Frontend-testen is een dekeneterm die een verscheidenheid aan geautomatiseerde teststrategieën omvat. Sommige van deze, zoals eenheid en integratie testen, zijn al jaren een geaccepteerde beste praktijk in de backend-ontwikkelingsgemeenschap. Andere strategieën zijn nieuwer en voort uit de veranderingen in welke backend- en frontend-ontwikkeling worden voor nu gebruikt.

Tegen het einde van dit artikel moet u zich comfortabel voelen bij het beoordelen van welke teststrategieën het beste passen bij uw team en codebases. De volgende code-voorbeelden worden geschreven met behulp van het jasmijnkader, maar de regels en processen zijn vergelijkbaar in de meeste testkaders.

• Beste stukjes gebruikerstestsoftware

01. Eenheidstests

Eenheidstests, een van de testveteranen, is op het laagste niveau van alle testtypen. Het doel is om ervoor te zorgen dat de kleinste stukjes van uw code (genaamd eenheden) onafhankelijk functioneren zoals verwacht.

Stel je voor dat je een LEGO-set hebt voor een huis. Voordat u begint met het bouwen, wilt u ervoor zorgen dat elk individueel stuk wordt verantwoord (vijf rode vierkanten, drie gele rechthoeken). Eenheidstests zorgt ervoor dat individuele sets van code - dingen zoals invoervaliden en berekeningen - werken zoals bedoeld voordat ze de grotere functie bouwen.

Het helpt om na te denken over Unit-tests in Tandem met het 'Do Eén ding Well' Mantra. Als u een stuk code hebt met een enkele verantwoordelijkheid, wilt u waarschijnlijk een eenheidstest voor het schrijven.

Laten we naar het volgende codefragment kijken, waarin we een eenheidstest schrijven voor een eenvoudige rekenmachine:

 Beschrijf ("Calculator Operations", functie () {
  het ("moet twee nummers toevoegen", functie () {
    Rekenmachine.init ();
    Var Result = Calculator.AddNummers (7,3);
    verwachten (resultaat) .tobe (10);
  ​
}); 

In onze Rekenmachine Toepassing, we willen ervoor zorgen dat de berekeningen altijd onafhankelijk functioneren zoals we verwachten. In het voorbeeld willen we ervoor zorgen dat we altijd nauwkeurig twee getallen samen kunnen toevoegen.

Het eerste wat we doen is de reeks van tests beschrijven die we gaan rennen met het gebruik van Jasmine's beschrijven ​Dit creëert een testsuite - een groepering van tests met betrekking tot een bepaald deel van de toepassing. Voor onze rekenmachine zullen we elke berekeningstest in zijn eigen suite groeperen.

Suites zijn geweldig niet alleen voor codorganisatie, maar omdat ze je in staat stellen om suites alleen uit te voeren. Als u aan een nieuwe functie werkt voor een toepassing, wilt u niet elke test uitvoeren tijdens actieve ontwikkeling, omdat dat zeer tijdrovend zou zijn. Testende suites kan je individueel sneller ontwikkelen.

Vervolgens schrijven we onze eigenlijke tests. De ... gebruiken het Functie, we schrijven de functie of het stuk functionaliteit dat we testen. Ons voorbeeld testen de toevoegingsfunctie, dus we zullen scenario's uitvoeren die bevestigen dat het correct werkt.

Vervolgens schrijven we onze testbewering, waar we testen zijn als onze code functioneert zoals we verwachten. We initialiseren onze rekenmachine en voeren onze addnummers Functie met de twee nummers die we willen toevoegen. We slaan het nummer op als resultaat en beweren dat dit gelijk is aan het aantal dat we verwachten (in onze zaak, 10).

Als addnummers Nooit de juiste cijfers terug te sturen, zal onze test mislukken. We zouden soortgelijke tests schrijven voor onze andere berekeningen - aftrekken, vermenigvuldiging, enzovoort.

02. Acceptatietests

Als de eenheidstests zijn als het controleren van elk LEGO-stuk, controleren acceptatietests als elke fase van het gebouw kan worden voltooid. Alleen omdat alle stukken worden verantwoord, betekent niet dat de instructies correct uitvoerbaar zijn en u in staat stellen om het uiteindelijke model te bouwen.

Acceptatietests gaan door uw bedrijfsapplicatie en zorgen voor aangewezen acties, gebruikersinvoer en gebruikersstromen zijn voltooid en functioneren.

Alleen omdat onze applicatie's addnummers Functie retourneert het juiste nummer, betekent niet dat de Calculator-interface zeker zal functioneren zoals verwacht om het juiste resultaat te geven. Wat als onze knoppen zijn uitgeschakeld of het berekeningsresultaat niet wordt weergegeven? Acceptatietests helpen ons deze vragen te beantwoorden.

 Beschrijf ("Registreer Failure Status", functie () {
  het ("mag aanmelden niet toestaan ​​met ongeldige informatie", functie () {
    Var-pagina = Bezoek ("/ Home");
    Pagina.Fill_in ("Input [Name = 'E-mail']", "Geen e-mail");
    pagina. Klik ("knop [type = indienen]");
    pagina. Klik ("knop [type = indienen]");
    Verwacht (pagina. Find ("# Signuperror"). Hasclass ("verborgen")). TOBFALSY ();
  ​
}); 

De structuur lijkt erg op onze eenheidstest: we definiëren een suite met beschrijven en schrijf vervolgens onze test in de het functie, voer vervolgens een code uit en controleer de uitkomst.

In plaats van te testen op specifieke functies en waarden, het testen hier echter om te zien of een bepaalde workflow (een aanmeldingsstroom) gedraagt ​​zoals verwacht wanneer we een aantal slechte informatie invullen. Er zijn hier mertere acties die hier gebeuren, zoals formulier-validaties die mogelijk eenheid zijn getest, evenals elke hantering voor wat onze foutstaat toont, aangetoond door een element met de ID Signuperror ​

Acceptatietests zijn een geweldige manier om ervoor te zorgen dat de sleutelervaringsstromen altijd correct werken. Het is ook gemakkelijk om tests rond randcases toe te voegen en om uw QA-teams te helpen ze in uw toepassing te vinden.

Bij het overwegen van wat te schrijven acceptatietests voor, zijn uw gebruikersverhalen een geweldige plek om te beginnen. Hoe werkt uw gebruiker om met uw website, en wat is de verwachte uitkomst van die interactie? Het is anders dan eenheidstests, die beter afgestemd is op iets als functievereisten, zoals de vereisten rond een gevalideerd veld.

03. Visuele regressietests

Zoals vermeld in de introductie, zijn sommige soorten testen uniek voor de frontend-wereld. De eerste hiervan is visuele regressietests. Dit test uw code niet, maar vergelijkt het weergegeven resultaat van uw code - uw interface - met de gerenderde versie van uw toepassing in productie, enscenering of een vooraf gewijzigd lokale omgeving.

Dit wordt meestal gedaan door screenshots te vergelijken die zijn gemaakt in een hoofdloze browser (een browser die op de server loopt). Beeldvergelijkingsgereedschap Detecteer vervolgens eventuele verschillen tussen de twee opnamen.

Met behulp van een tool zoals PhantomSSS, geven uw tests op waar de testloper moet navigeren, een screenshot maken en het raamwerk laat zien dat de verschillen in die opvattingen kwamen.

 Casper.start ("/ home"). Dan (functie () {

  // aanvankelijke staat van vorm
  PhantomCS.screenshot ("# Signupform", "Meldingsvorm");

  // Druk op de knop Aanmelden (zou fout moeten triggeren)
  Casper.Click ("knop # Signup");

  // Neem een ​​screenshot van de UI-component
  PhantomCS.screenshot ("# aanmeldingformulier", "Meldingsformulier aanmelden");

  // Vul formulier in op naam Attributes & AMP; indienen
  Casper.fill ("# Signupform", {
    Naam: "Alicia Sedlock",
    E-mail: "[email protected]"
  }, waar);

  // Neem een ​​tweede screenshot van successtatus
 PhantomCS.Screenshot ("# Signupform", "Melding van formulier succes");
}); 

In tegenstelling tot acceptatie- en eenheidstests, is visuele regressietests moeilijk te profiteren als u iets nieuws brengt. Naarmate je UI snelle en drastische veranderingen zal zien in de loop van de actieve ontwikkeling, bewaar je waarschijnlijk deze tests voor wanneer stukjes van de interface visueel zijn voltooid. Daarom zijn visuele regressietests de laatste tests die u moet schrijven.

Momenteel vereisen veel visuele regressiestools een beetje handmatige inspanning. Mogelijk moet u uw screenshot-opname uitvoeren voordat u de ontwikkeling op uw branche start, of de basislijnscreenshots handmatig bijwerken terwijl u wijzigingen aanbrengt in de interface.

Dit is simpelweg vanwege de aard van ontwikkeling - veranderingen in de Ui Kan opzettelijk zijn, maar de tests kennen alleen maar 'ja, dit is hetzelfde' of 'nee, dit is anders'. Echter, als visuele regressies een pijnpunt in uw toepassing zijn, kan deze aanpak uw teamtijd en moeite in het algemeen opslaan in vergelijking met constant bevestigingsregries.

04. Toegankelijkheid en prestatietests

Naarmate de cultuur en het bewustzijn rond frontend testen groeit, groeit dit ook om verschillende aspecten van het ecosysteem te testen. Gezien de toegenomen focus op toegankelijkheid En de prestaties in onze technische cultuur, die dit integreert in uw testsuite helpt ervoor te zorgen dat deze concepten een prioriteit blijven.

Als u problemen hebt met de handhaving van prestatiebudgetten of toegankelijkheidsnormen, is dit een manier om deze vereisten in de voorhoede van de geesten van mensen te houden.

Beide controles kunnen worden geïntegreerd in uw workflow met build-tools zoals GRUNP, of Semi-handmatig in uw terminal. Voor prestatiebudgetten geeft een tool zoals GRUT-PERFBUDGET u de mogelijkheid om uw site via Webpagetest automatisch binnen een opgegeven taak uit te voeren.

Als u echter geen taakrunner gebruikt, kunt u perfbudget ook pakken als een stand-alone NPM-module en de tests handmatig uitvoeren.

Dit is hoe het eruit ziet om dit door de terminal te rennen:

 PERFBUDGET --URL http://www.alicability.com - Toets [WebpagetTEST API-sleutel] --SpeedIndx 2000 - RENDER 400

En eveneens, instellen via GRUNT:

PERFBUDGET: {
  standaard: {
    Opties: {
      URL: 'http://alicity.com',
      Sleutel: 'Webpagetest API-sleutel',
      Budget: {
        SpeedIndex: '2000',
        Render: '400'
      ​
    ​
  ​
​

​

GRUT.REGISTERTASK ('standaard', ['JSHINT', 'PERFBUDGET']); 

Dezelfde opties zijn beschikbaar voor toegankelijkheidstests. Dus voor PA11Y, kun je de PA11Y Commando in uw browser voor uitvoer of stel een taak in om deze stap te automatiseren. In de terminal:

 PA11Y Allicity.com

// als een JavaScript-opdracht na NPM-installatie

Var PA11Y = vereisen ('PA11Y'); // vereisen pa11y
Var Test = PA11Y (); // KRIJG PA11Y klaar om in te stellen

Test.Run ('Alicability.com', functie (fout, resultaten) {
  // Log ons af tijdens uw resultaten
}); 

De meeste hulpmiddelen in deze categorieën zijn redelijk plug-and-play, maar geven u ook de mogelijkheid om aan te passen hoe de tests worden uitgevoerd - u kunt ze bijvoorbeeld instellen om bepaalde WCAG-normen te negeren.

Volgende pagina: Hoe introduceren te testen in uw workflow

• 1
• 2

Huidige pagina: Verschillende soorten frontend-tests (en wanneer ze ze gebruiken)