hoe Test u uw Web Apps

in de software-industrie test iedereen zijn apps op een bepaalde manier. Veel ontwikkelaarsteams hebben uitgebreide testschema ‘ s die goed geïntegreerd zijn met hun continue integratiepijpleidingen, maar zelfs degenen die geen automatische tests hebben, moeten nog steeds manieren bedenken om te controleren of hun code naar behoren functioneert.

een website bouwen en er handmatig door klikken met behulp van een browser is een verscheidenheid aan testen. Hoewel het niet de meest geavanceerde is, telt het nog steeds. Hetzelfde geldt voor het afvuren van krul in de console en het verzenden van een synthetisch verzoek aan de API-eindpunt dat u zojuist hebt gemaakt.

dit artikel zal bespreken hoe we de handmatige tests die we al doen kunnen automatiseren voordat we ingaan op verschillende testtypes en methodologieën.

het automatiseren van Tests

handmatige tests zijn voldoende voor kleine apps, maar wanneer deze apps groeien, groeit hun testbare oppervlak met hen, waardoor twee problemen.

Eén, wanneer mensen tests moeten uitvoeren telkens wanneer een nieuwe versie van een app is voltooid, kunnen er inconsistenties ontstaan. Dit geldt vooral als er veel tests zijn. Twee: de persoon die de tests doet, kan geen andere taken uitvoeren. Met grote apps kan het testen meerdere dagen duren.

de meest logische manier om deze twee problemen op te lossen is het automatiseren van deze handmatige taken. Er bestaan twee soorten tests voor webapps: UI-tests en API-tests. Twee gereedschappen kunnen ze automatiseren.

UI-Tests

UI-tests kunnen worden uitgevoerd met een tool genaamd Puppeteer. Puppeteer kunt u een handmatige UI-test te automatiseren met behulp van JavaScript. Het wordt geïnstalleerd via NPM met het volgende commando:

 $ npm i puppeteer

u kunt dan een script schrijven dat een headless versie van Chrome bestuurt om uw tests uit te voeren. Dit script zou er als volgt uit kunnen zien:

(async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://google.com', {waitUntil: 'networkidle2'}); const heading = await page.$('h1'); await browser.close(); if(!heading) console.log('No heading found!');})();

In dit script, we beginnen een headless instantie van Chrome, navigeren naar example.com en op zoek naar een H1 element. Als het niet bestaat, wordt een foutmelding gelogd.

API-Tests

API-tests kunnen worden geautomatiseerd via de postbode. Postman wordt geleverd met een grafische interface voor het bouwen van HTTP-verzoeken die kunnen worden opgeslagen. Deze verzoeken kunnen later worden uitgevoerd met slechts een muisklik.

om te beginnen, download en installeer de Postman UI. De volgende stappen zijn nodig om een aanvraag te maken en op te slaan:

1. klik op Create a Collection on the left
2. Enter My Collection as the collection name
3. Click Create
4. Click on the ellips (…) of My Collection on the left
5. select Add Request
6. Enter My Request as the request name
7. click Save to My Collection

het verzoek verschijnt in de linkerzijbalk onder uw nieuw-creëerde collectie.

als u het selecteert, moet u invoeren example.com als een URL en voeg een test. Om een test toe te voegen, klikt u op testen in de tabbalk Onder het URL-invoerveld.

er verschijnt een tekstgebied waarin u uw test in JavaScript kunt schrijven. Het volgende is een voorbeeld van een test:

pm.test("Status code is 200", () => { pm.response.to.have.status(200);});

als u op Opslaan in de rechterbovenhoek van het scherm klikt en direct daarna verstuurt, wordt uw verzoek verzonden. Het testscript zal dan uitvoeren om te bepalen of de reactie status 200 had of niet.

soorten Tests

er zijn drie verschillende soorten tests. Als u ze begrijpt, kunt u het juiste type testen kiezen voor de verschillende onderdelen van uw softwarestack.

eenheidstests

eenheidstests zijn het eenvoudigste type test. Zij controleren de juistheid van kleine delen van uw code. Een unit test omvat meestal één aanroep naar een functie of een manier om een klasse te gebruiken.

een unit test is meestal de eerste “gebruiker” van uw code. Sommige testmethodologieën vereisen zelfs dat u de test schrijft voor de implementatie van de eigenlijke toepassingscode.

Unit tests kunnen worden gebruikt in zowel backend als frontend ontwikkeling. Sommige ontwikkelteams gebruiken unit tests om de weergegeven DOM-uitvoer van kleine delen van hun code te controleren, zoals formulieren of menu ‘ s. In de backend worden unit tests vaak gebruikt om de code tussen de HTTP-server en de database of andere API ‘ s te testen.

drie veel gebruikte testrunners voor unit tests zijn:

‐ Jest-Jest wordt meestal gebruikt in frontend ontwikkeling omdat het wordt geleverd met unieke functies, zoals snapshot testen, die helpen bij problemen zoals UI regressies. Een grap tutorial is hier te vinden.

– AVA-AVA is favoriet in backend ontwikkeling omdat het gespecialiseerd is in zeer parallelle uitvoering van tests. Een AVA tutorial is hier te vinden.

– PHPUnit-PHPUnit is een populair framework voor unit tests in PHP. Een PHPUnit tutorial is hier te vinden.

als een eenheidstest een aantal externe bronnen vereist, zoals netwerkverbindingen of databases, dan schrijf je waarschijnlijk een integratietest. Dit type test wordt hierna behandeld.

integratietests

vanuit een implementatieperspectief zien integratietests eruit als eenheidstests. Het verschil is dat integratietests meerdere delen van de stack samen testen. Ze kunnen bijvoorbeeld testen of de client en server hetzelfde protocol spreken of, in een microservices-architectuur, of de services al dan niet correct samenwerken.

controles die gewoonlijk in meerdere onafhankelijke eenheidstests zouden eindigen, kunnen worden samengevoegd tot één integratietest die bepaalt of alles goed samen werkt.

integratietests worden gebruikt in zowel frontend-als backend-ontwikkeling. Ze worden soms gebruikt om te zien of de twee delen correct interageren, maar ze kunnen ook worden gebruikt om te bepalen of verschillende modules van een deel samenwerken zoals bedoeld.

u kunt dezelfde testrunners gebruiken voor integratietests die u hebt gebruikt voor eenheidstests. Postman, de UI-tool die hierboven wordt gebruikt om handmatige API-tests te automatiseren, wordt echter ook geleverd met een CLI-tool genaamd Newman die kan worden geïntegreerd met uw CI/CD-pijplijn.

Newman kan geëxporteerde Postman-collecties uitvoeren, zodat u aanvragen en tests kunt maken met de Postman-gebruikersinterface en deze later kunt uitvoeren via CLI. Een Newman tutorial is hier te vinden.

als een integratietest interactie met de gebruikersinterface vereist, wordt het een gebruikersinterface—test-addressed next genoemd.

UI-Tests

UI-tests zijn de meest geavanceerde tests. Ze proberen gebruikersgedrag op een geautomatiseerde manier te emuleren, zodat testers niet handmatig door elk deel van hun app hoeven te klikken.

UI-tests helpen vaak om een specifieke interactie vast te leggen die leidde tot een fout voor een gebruiker. Zodra het is vastgelegd, kan het worden gereproduceerd met één klik om de bug op te lossen en te voorkomen dat het terugkomt in een nieuwe versie.

de eerder genoemde Jest-en AVA-testrunners kunnen hier worden gebruikt, maar u hebt meestal een extra bibliotheek nodig om de interactie met de gebruikersinterface via een browser te vergemakkelijken. De twee belangrijkste bibliotheken die momenteel in gebruik zijn voor dit proces zijn:

‐ Puppeteer—Puppeteer is een JavaScript bibliotheek die wordt geleverd met een headless implementatie van Chrome die het mogelijk maakt om UI-tests programmatisch op de achtergrond uit te voeren. Een poppenspeler tutorial is hier te vinden.

– Selenium-Selenium is een framework dat de afstandsbediening van een browser mogelijk maakt via een bibliotheek genaamd WebDriver. Een selenium tutorial is hier te vinden.

er zijn meer soorten tests dan de hier vermelde. Anderen kunnen verschillende doelen hebben; bijvoorbeeld, load tests proberen om prestaties knelpunten te vinden. Houd er rekening mee dat de hier beschreven tests soms verschillende namen krijgen. De drie hierboven gepresenteerde types zijn de essentiële om te implementeren wanneer aan de slag. Met behulp van een van hen is beter dan het gebruik van geen geautomatiseerde testen op alle.

testmethoden

testmethoden zijn manieren om na te denken over testen. De drie hieronder beschreven zijn de meest gebruikte.

Test Driven Development (TDD)

TDD is de meest gebruikte en de meest technische methode. Het adviseert dat u uw tests schrijft voordat u de eigenlijke code schrijft die u wilt testen. Aangezien je alleen een test moet schrijven voor het deel van de code dat je implementeert, is het type test dat je schrijft een unit test.

eenheidstests zijn nogal korrelig, dus na verloop van tijd resulteert het gebruik van deze methode in de accumulatie van vele tests. Deze realiteit, in combinatie met het feit dat beginnende TDD beoefenaars de neiging hebben triviale tests te schrijven, kan leiden tot de creatie van een stapel nutteloze tests. Om dit te voorkomen, is het cruciaal om tests bij te werken en op te ruimen wanneer het team meer vertrouwd is geraakt met TDD en met testen in het algemeen.

het is belangrijk om de tests regelmatig uit te voeren, niet alleen in een CI/CD pijplijn, maar ook lokaal op je ontwikkelmachine. Schrijf een test, voer het uit, zie het mislukken, implementeer genoeg om de test te laten slagen, en herhaal het proces.

voor meer informatie, bekijk Agile Alliance ‘ s beschrijving van TDD.

Acceptance Test Driven Development (Atdd)

ATDD is een wijziging van TDD die zich meer richt op business cases en minder op technische implementatie. De testtypen die in deze methodologie worden gebruikt zijn meestal integratietests, omdat vaak meerdere onderdelen van het systeem moeten worden gebruikt in combinatie met een zakelijke behoefte op te lossen.

aangezien de tests minder technisch zijn, is het ook raadzaam om niet-technisch georiënteerde personen bij het testproces te betrekken. Producteigenaren en klanten kunnen helpen om de business cases te definiëren, zodat een ontwikkelaar een test voor hen kan schrijven. Als de test niet succesvol kan worden uitgevoerd, is het duidelijk dat er meer functionaliteit moet worden geïmplementeerd.

ATDD werkt op een ander abstractieniveau dan TDD, zodat de twee methoden samen kunnen worden gebruikt.

voor meer informatie, bekijk Agile Alliance ‘ s beschrijving van TDD.

Behavior Driven Development (BDD)

BDD is een mix van TDD en ATDD, en het doel is om het beste van beide werelden te gebruiken om het algehele systeem stabieler te maken. BDD probeert een systeem te specificeren met tests die het gebruik ervan illustreren.

net als ATDD probeert BDD businesscases vast te leggen. Echter, het vereist ook dat je deze use cases in vraag stelt met de “5 whys ” omdat de” whys ” een ontbrekende deel zijn in ATDD. Zeker, het is beter om klanten te vragen wat ze willen in plaats van alleen te vertrouwen op de input van de ontwikkelaar. Maar het is ook belangrijk om de aannames van beide groepen in vraag te stellen.

BDD is ook een mix van TDD en ATDD in de zin van abstractieniveaus. TDD test alleen de kleine onderdelen van uw applicatie en ATDD test alleen hoe deze onderdelen samenwerken. BDD vereist dat u deze methodologie toepast op het grote geheel van uw app en zijn kleine onderdelen, waardoor BDD een meer holistische benadering van testen is.

voor meer informatie, bekijk Agile Alliance ‘ s beschrijving van BDD.

conclusie

hoewel geen testen slecht is, is handmatig testen beter en is geautomatiseerd testen het beste.

afhankelijk van de grootte van uw app, kan een handmatige test de leden van het ontwikkelteam dagen of zelfs weken beletten om aan andere projecten te werken, wat uw bedrijf tijd en geld kost. Bovendien kan de eentonige taak van het uitvoeren van dezelfde interacties over en weer leiden tot slippen die zich vaak manifesteren in ongepakte bugs.

Computers zijn erg goed in het steeds opnieuw herhalen van dezelfde taak, dus het is een goed idee om testen te delegeren aan een script en de tijd van uw ontwikkelaars vrij te maken. Als deze tests zijn geà ntegreerd in je CI/CD pijplijn, kunnen de reeds geschreven tests gewoon impliciet draaien wanneer een nieuwe commit in je repositories landt.

het is een goed idee om in een vroeg stadium een testmethode te gebruiken, omdat vaak de grote problemen bij het starten “wat” en “wanneer” zijn om te testen. Deze methodologieën kunnen helpen om een proces te verduidelijken dat het schrijven van tests consistenter maakt voor alle leden van het team.