Testen zonder Testteam

Hier is het ongemakkelijke feit over vibe coden: de meeste AI-gegenereerde code wordt verscheept zonder serieuze tests. En dat is een probleem. Niet omdat testen leuk is (dat is het zelden), maar omdat bugs in productie je gebruikers kosten, je reputatie schaden en je meer tijd kosten dan testen ooit zou hebben gedaan.

Maar je hebt geen QA-afdeling. Geen testteam. Misschien zelfs geen testervaring. En dat is precies waarom deze module bestaat. Want het goede nieuws is: dezelfde AI die je code schrijft, kan ook je tests schrijven. En de nieuwste generatie testtools laat je in gewone taal beschrijven wat je wilt testen.

In deze module leer je een testaanpak die praktisch, haalbaar en effectief is voor solo-builders en kleine teams. Geen academische testtheorie, maar concrete technieken die je vandaag kunt toepassen.

Laten we eerlijk zijn over wat er gebeurt als je niet test.

Professionele testers werken met een “testpiramide”: veel kleine, snelle tests aan de basis, minder uitgebreide tests in het midden, en een paar grote tests aan de top. Als solo vibe coder volg je hetzelfde principe, maar met een pragmatische invulling.

Niveau 1: Handmatig testen (de basis)

Dit is het minimum dat je bij elke wijziging doet. Het kost geen setup, geen tools en geen kennis. Alleen discipline.

Wat je test:

• Werkt de kernfunctie? (de actie die je app bestaansrecht geeft)
• Werkt de navigatie? (kan de gebruiker overal komen?)
• Werken formulieren? (validatie, opslaan, foutmeldingen)
• Werkt het op mobiel? (responsive check)
• Wat gebeurt er bij lege input? Bij foute input?

Wanneer je test: Na elke prompt die iets verandert. Niet aan het einde van de dag. Na elke wijziging. Dit klinkt overdreven, maar elke test duurt dertig seconden tot twee minuten. Een bug die je nu vangt, kost je straks geen uur.

De verse-ogen test: Open je app in een incognito/privébrowser. Geen ingelogd account, geen testdata. Ervaar je app als een nieuwe gebruiker. Waar loop je vast? Wat is verwarrend? Dit simpele ritueel vangt meer problemen dan welke automatische test ook.

Niveau 2: AI-gegenereerde unit tests

Unit tests controleren of individuele functies correct werken. Ze zijn snel, automatisch, en ideaal om door AI te laten schrijven. Dit is een van de taken waar AI het meest uitblinkt.

Wat zijn unit tests? Een unit test is een stukje code dat een specifieke functie aanroept met bekende input en controleert of de output klopt. Bijvoorbeeld: je hebt een functie die BTW berekent. De unit test roept die functie aan met € 100 en controleert of het resultaat € 121 is.

Wanneer unit tests schrijven: Na het bouwen van elke functie die berekeningen doet, data transformeert, of business logica bevat. Je hoeft niet elke knop en elk UI-element te unit-testen. Focus op de logica.

Niveau 3: End-to-end tests (de gebruikersreis)

End-to-end tests simuleren een echte gebruiker die door je app navigeert. Ze openen een browser, klikken op knoppen, vullen formulieren in en controleren of het resultaat klopt. Dit is het meest waardevolle type test, maar ook het meest tijdrovend om op te zetten.

Wanneer end-to-end tests schrijven: Voor je kritieke gebruikersflows. Als je app een facturatietool is: test het complete pad van inloggen, factuur aanmaken, opslaan en terugvinden. Als een van die stappen breekt, wil je dat weten voor je gebruikers het merken.

Net zoals vibe coden je laat programmeren in gewone taal, laat vibe testing je testen in gewone taal. Je beschrijft wat je wilt testen, en een AI-agent voert de test uit in een echte browser, precies zoals een menselijke tester dat zou doen.

Dit is geen toekomstmuziek. De tools bestaan nu en ze zijn in 2026 volwassen genoeg voor serieus gebruik.

Hoe het werkt

In plaats van testcode te schrijven, beschrijf je je test in gewone taal:

De AI-agent opent een echte browser, navigeert je app, voert de stappen uit en rapporteert of alles werkt. Als iets faalt, krijg je een screenshot van waar het misging en een beschrijving van het probleem.

De meest effectieve testaanpak voor vibe coders is simpel: test na elke prompt. Niet aan het einde van de dag, niet voor de deploy, maar na elke individuele wijziging.

Stap 1: Schrijf je prompt

Beschrijf wat je wilt bouwen of wijzigen (zie Module 5 voor prompttechnieken).

Stap 2: Bekijk het resultaat

Lees de gegenereerde code. Je hoeft niet elke regel te begrijpen, maar scan op dingen die niet kloppen: ontbrekende validatie, hardcoded waarden, functies die verdacht lang zijn.

Stap 3: Test handmatig

Open je app. Werkt de wijziging? Test het normale pad (het werkt zoals verwacht) en het abnormale pad (wat gebeurt er bij foute input, lege velden, of onverwachte acties?).

Stap 4: Laat AI een test schrijven

Na elke significante feature, vraag de AI om een test te schrijven die controleert of de feature werkt.

Stap 5: Draai alle bestaande tests

Niet alleen de nieuwe test, maar alle tests. Elke keer. Dit vangt de verrassingsbugs: wijzigingen die onbedoeld iets anders breken.

Stap 6: Commit en ga verder

Alles werkt? Commit naar Git. Ga door naar de volgende prompt. Als iets niet werkt: fix het nu, niet later.

Je kunt niet alles testen. Dat is ook niet nodig. De kunst is focus aanbrengen op de dingen die het meest impact hebben als ze falen.

Voor elke deploy naar productie, loop deze checklist af. Print hem uit, hang hem naast je scherm, en sla hem nooit over.

Tot nu toe heb je handmatig en lokaal getest. Maar wat als je tests automatisch draaien elke keer dat je code pusht? Dat is continuous testing, en het is makkelijker op te zetten dan je denkt.

Wat is continuous testing?

Elke keer dat je code pusht naar GitHub, draait een systeem automatisch al je tests. Als een test faalt, krijg je een melding en wordt de deploy geblokkeerd. Geen kapotte code meer in productie.

Hoe zet je het op?

De meeste vibe coders gebruiken GitHub Actions. Het is gratis voor publieke repositories en heeft een genereuze gratis tier voor private repositories.

De workflow draait nu automatisch bij elke push. Je ziet een groen vinkje als alles slaagt en een rood kruisje als iets faalt. Vercel en Netlify respecteren deze checks: als de tests falen, wordt niet gedeployed.

Elke keer dat je een nieuwe feature bouwt en daar een test voor schrijft, wordt die test automatisch meegenomen in de workflow. Je testsuite groeit organisch met je project.

De grootste blinde vlek van elke bouwer is dat je weet hoe je app werkt. Je test altijd het “gelukkige pad”: de route die je hebt ontworpen. Maar je gebruikers nemen routes die je nooit hebt bedacht.

Je hoeft geen uitgebreid testdocument te schrijven. Dit simpele template is genoeg. Vul het in voor je project, hang het naast je scherm, en volg het bij elke deploy.