Introductie

Je denkt misschien: "Waarom zou ik tests schrijven? Ik kan toch zelf checken of mijn app werkt?"

Dat is een logische gedachte. En je hebt gelijk: je kunt je app openen, op buttons klikken, formulieren invullen en zien of alles werkt.

Maar laat me je laten zien waarom testen uiteindelijk tijd bespaart en je een betere developer maakt.

"Maar ik kan het toch zelf testen?"

Ja, dat klopt! Je kunt je app openen, op buttons klikken, formulieren invullen... Maar bedenk dit:

Scenario: Je bouwt een Todo app

Om ALLES handmatig te testen moet je elke keer:

  1. De app starten (30 seconden wachten)
  2. Een todo toevoegen en checken of het werkt
  3. Een todo verwijderen en checken of het werkt
  4. Een todo als "done" markeren en checken of het werkt
  5. Checken of alles blijft staan na refresh
  6. Checken wat er gebeurt met lege input
  7. Checken wat er gebeurt met heel lange todo tekst
  8. Checken of de filter buttons werken (All, Active, Completed)

Tijd per handmatige test: 5-10 minuten

Als je iets verandert in je code: Doe het OPNIEUW

Na 10 code wijzigingen: 50-100 minuten verspild aan klikken!

Het probleem wordt groter

Naarmate je app groeit, wordt handmatig testen steeds tijdrovender:

  • 5 features = 25 minuten handmatig testen
  • 10 features = 50 minuten handmatig testen
  • 20 features = 100 minuten handmatig testen

En dit moet je doen na ELKE wijziging. Want hoe weet je zeker dat je nieuwe code niks anders heeft gebroken?

Tests Besparen Uiteindelijk Tijd

"Maar tests schrijven kost toch ook tijd?"

Ja, dat klopt. Eerste keer kost het tijd. Maar daarna bespaar je enorm veel tijd!

Met Jest tests:

  1. Schrijf de test 1x (kost 10 minuten)
  2. Run alle tests: npm run test
  3. Resultaat binnen 2 seconden
  4. Elke keer als je iets wijzigt: npm run test (2 seconden)

Rekensom:

Tests schrijven: 10 minuten

Na 10 wijzigingen: 10 minuten + (10 × 2 seconden) = 10 minuten 20 seconden

vs

Handmatig: 10 × 5 minuten = 50 minuten

Besparing: 40 minuten!

Break-even punt

Je verdient de tijd van tests schrijven terug na ongeveer 2-3 wijzigingen. Daarna is het pure winst.

Realistisch voorbeeld:

Je bouwt een webshop met winkelwagen functionaliteit. Je test het handmatig, alles werkt. Een week later voeg je een kortingscode feature toe. Je test de kortingscode... maar vergeet te checken of de winkelwagen nog steeds werkt. Je pusht de code. De volgende dag klagen gebruikers dat de winkelwagen leeg blijft.

Met tests? Je draait npm run test en ziet direct: "Winkelwagen test gefaald - items worden niet toegevoegd". Je lost het op VOORDAT gebruikers het merken.

Tests als Vangnet

Je breekt dingen zonder het te weten

Dit overkomt ELKE developer:

Veelvoorkomende situatie:

Je hebt een button component gemaakt. Het werkt perfect! Je test het, het werkt. Je commit de code.

Een week later pas je de CSS aan om de button mooier te maken. Je checkt alleen of de styling goed is. Maar... je hebt per ongeluk de onClick verwijderd uit de code.

Zonder tests: Je merkt het pas als een gebruiker klaagt dat buttons niet werken.

Met tests: Je draait npm run test. Direct zie je: "Button test gefaald - onClick werkt niet". Je lost het in 30 seconden op.

Tests geven je vertrouwen

Met tests durf je te refactoren. Je weet: als alle tests slagen, werkt de app nog.

Zonder tests: "Ik durf deze functie niet te veranderen, misschien breek ik iets"

Met tests: "Ik verander de functie, run de tests... alles groen! Ik ben safe."

Edge cases die je vergeet

Handmatig testen vergeet je vaak edge cases:

  • Wat als de input leeg is?
  • Wat als iemand 1000 karakters typt?
  • Wat als iemand 100x op de button klikt?
  • Wat als de API traag is?

Met tests schrijf je deze edge cases 1x. Dan worden ze ALTIJD getest.

Wat Bedrijven Eisen

In de echte wereld is testen geen optie, het is een verplichting.

Standaard in bedrijven

  • De meeste bedrijven EISEN tests voor belangrijke code
  • Je mag soms niet eens code pushen zonder tests
  • Code reviews: collega's checken of je tests hebt geschreven
  • Als je test coverage onder 80% zakt, mag je code niet live

CI/CD Pipelines

Moderne bedrijven gebruiken CI/CD (Continuous Integration / Continuous Deployment):

Hoe het werkt:

  1. Je pusht code naar GitHub
  2. Automatisch draaien alle tests
  3. Als 1 test faalt, gaat je code NIET live
  4. Als alle tests slagen, gaat je code automatisch naar productie

Tests zijn de gatekeeper. Zonder tests, geen deployment.

Stage vs Junior developers

Wil je opvallen tijdens je stage of eerste baan?

Junior zonder tests:

"Deze feature werkt, ik heb het getest"

Junior met tests:

"Deze feature werkt, hier zijn de tests. Code coverage is 95%. Alle edge cases zijn gedekt."

Wie denk je dat meer indruk maakt?

Investering in je toekomst

Tests leren is investeren in je carrière als developer:

  • Elk bedrijf gebruikt tests
  • Het staat goed op je CV
  • Je leert denken in edge cases
  • Je schrijft betere, betrouwbaardere code

Conclusie

Ja, tests schrijven kost tijd.

Maar:

  • Je verdient die tijd terug na 2-3 wijzigingen
  • Tests vangen bugs voordat gebruikers ze zien
  • Je krijgt vertrouwen om code te veranderen
  • Bedrijven verwachten het van je
  • Het maakt je een betere developer

De mindset shift

Stop met denken: "Ugh, ik MOET tests schrijven"

Start met denken: "Tests zijn mijn vangnet. Ze maken me sneller en zekerder."

Praktisch advies:

Begin klein. Je hoeft niet alles te testen. Begin met:

  • Belangrijke functies (bijv. prijs berekenen)
  • Complexe logica (bijv. validatie)
  • Dingen die vaak breken

Naarmate je beter wordt in testen, gaat het sneller en wordt het een gewoonte.

Klaar om te beginnen?

Nu je weet WAAROM testen belangrijk is, tijd om te leren HOE: