De vertaling van [Het V-Model](craftdocs://open?blockId=45A84203-1C9C-4C84-BD65-D42CD50A9D4A&spaceId=2154107e-b0ee-4453-f8fd-57edcda10041) naar test automatiseren heeft de vorm van een piramide gekregen: ![[Pasted image 20240731182351.png]] *Test automatiseringspiramide* De test automatisering piramide is een vertaling van de testsoorten naar een beschrijving van 3 levels van testautomatisering, hun relatie en hun belang. Mike Cohn beschrijft het concept van deze piramide in zijn boek Succeeding with Agile. Hoe hoger in de piramide hoe de uitvoeringstijd, complexiteit en dus ook de kosten. Hoe lager, en breder, de laag in de piramide hoe meer testen er voor uitgevoerd kunnen worden voor minder tijd, hogere betrouwbaarheid. Alle lagen samen vullen elkaar aan en zorgen voor maximaal haalbare test dekking. **Wat valt op:** - Handmatig testen blijft onderdeel van het test proces! - Unit tests nemen de meeste ruimte in en GUI de minste # De lagen van de test automatiserings piramide ## Unit Tests - Een door de ontwikkelaars uitgevoerde test om aan te tonen dat het systeem voldoet aan met name de technische specificaties. - Gericht op de code - Richt zich op componenten; kleine stukjes code. - Per component - Gebruik van Mockdata, geen afhankelijkheden! - Business Logica wordt getest **Voor en na-delen:** - Snel - Goedkoop - Makkelijk Onderhoudbaar > [!example] Inlogformulier voorbeeld > > - Controller-method van de API > - Handler met business logica > - Bijwerken van database ## Integratie Tests / API tests - Een door de leverancier uitgevoerde test om aan te tonen dat het systeem voldoet aan de functionele- en niet-functionele specificaties. - Integratietesten - Bewijzen dat alle afzonderlijke stukjes samenwerken. - Vanuit technisch perspectief (niet gebruikers perspectief) - Zo dicht mogelijk bij de bron. - Gericht op connectiviteit en functionaliteit - Zo min mogelijk GUI > Sneller en efficienter om bijvoorbeeld de API te testen **Voor en nadelen** Afhankelijkheden van andere systemen maken het instabieler en onderhoudsgevoelig > [!example] Voorbeeld: Inlogformulier > - API Call > - Optioneel foutsituaties; bijvoorbeeld wanneer n.a.v. API Call moet er iets gelogd worden. Tevens afhankelijk van risicoafweging. ## GUI tests - Automatiseren van handelingen van een gebruiker: Functionele testen - Voor het testen van de GUI - Vaak end-to-end - Raakt het meest en dus ook het meest complex **Voor en na-delen:** instabiel en onderhoudsgevoelig. Kost veel tijd en is dus duur > [!example] **Voorbeeld:** Inlogformulier > - Gebruiker logt in en zit het dashboard. > [!quote] *“De UI testen moeten tot het minimum worden beperkt en alleen worden gebruikt om vast te stellen of de gebruikersinterface correct is en niet om de business logica te testen. Het testen van de business logica is namelijk al gedaan tijdens de unittest en/of API- / integratietesten.“* Bron: [https://www.toets-je-parate-kennis-over.nl/software-testen/kennisbank/testautomatisering-piramide/](https://www.toets-je-parate-kennis-over.nl/software-testen/kennisbank/testautomatisering-piramide/) Ergens in je unit-testen zit als het goed is een test die checkt dat als iemand een foute combinatie username/password invult dat er een foutmelding komt. > [!quote] *Acceptance tests make sure a feature or use case is correctly implemented. It is similar to an integration test, but with a focus on the use case rather than on the components involved."* bron: [http://www.getlaura.com/testing-unit-vs-integration-vs-regression-vs-acceptance/](http://www.getlaura.com/testing-unit-vs-integration-vs-regression-vs-acceptance/)