Kwaliteitsborging & Testing
De Psychologie en Praktijk van Shift-Left Testing
Kwaliteit kan niet achteraf in software worden ingebouwd. In traditionele ontwikkelomgevingen wordt code eerst geschreven, waarna een afzonderlijk QA (Quality Assurance) team wekenlang handmatige tests uitvoert voor een release. Dit leidt steevast tot een eindeloze cyclus van bug-rapportages, context-switching en vertraagde opleveringen. De moderne IT-industrie lost dit op door testen ‘naar links te verschuiven’ (Shift-Left) in de levenscyclus: testen voordat of direct tijdens het schrijven van de code. Test-Driven Development (TDD) en geautomatiseerde End-to-End (E2E) testing zijn de steunpilaren van dit proces.
TDD is niet louter een test-strategie; het is primair een software-ontwerp-strategie. Het dwingt ontwikkelaars om na te denken over de architectuur en de vereisten van hun code voordat ze ook maar één regel logica schrijven.
De Red-Green-Refactor Cyclus van TDD
Test-Driven Development is gebouwd op een strikte, repetitieve cyclus, bekend als Red-Green-Refactor:
- Red: De ontwikkelaar schrijft éérst een unit test (vaak met Jest of JUnit) voor een zeer kleine functionaliteit die nog niet bestaat. Uiteraard faalt deze test direct (code is rood).
- Green: De ontwikkelaar schrijft vervolgens de meest simpele, rudimentaire code om de test te laten slagen (groen). Het is oké als deze code lelijk of gehardcode is; het enige doel is dat de test slaagt.
- Refactor: Omdat de code nu gedekt is door een test, kan de ontwikkelaar de lelijke code met vertrouwen herstructureren (refactoren) naar robuuste, geoptimaliseerde code, wetende dat de test direct zal falen als de functionaliteit onverhoopt kapot gaat.
Dit proces voorkomt over-engineering, garandeert 100% test-dekking voor bedrijfslogica, en resulteert in modules die inherent testbaar en dus ontkoppeld zijn.
De Piramide van Testing en de Evolutie van E2E
Een gezonde test-strategie volgt de Test-Piramide: een brede basis van duizenden snelle, geïsoleerde Unit Tests, een kleinere laag van Integratie Tests (die controleren of modules samenwerken met bijvoorbeeld de database), en een smalle top van End-to-End (E2E) tests. E2E tests emuleren een echte gebruiker die in een browser klikt, en controleren of het hele systeem van voorkant tot achterkant correct werkt.
Jarenlang was E2E-testing de achilleshiel van ontwikkelteams door broze, tergend trage test-suites aangedreven door Selenium. Tegenwoordig domineren moderne tools zoals Cypress en, nog indrukwekkender, Microsoft Playwright de markt. Playwright communiceert direct over het Chrome DevTools Protocol, wat resulteert in ongekende snelheid. Het ondersteunt parallelle test-executie, multi-browser tests (Chromium, WebKit, Firefox) uit de doos, en heeft ingebouwde ‘auto-wait’ functionaliteit, wat het beruchte probleem verhelpt van tests die crashen omdat de UI net iets te langzaam laadde.
Automatisering in de CI/CD Pipeline
Een test-suite is waardeloos als deze niet consequent wordt uitgevoerd. Daarom moeten Unit-, Integratie- en E2E-tests integraal onderdeel zijn van de CI/CD pipeline (bijv. GitHub Actions of GitLab CI). Wanneer een ontwikkelaar een Pull Request indient, worden alle tests geautomatiseerd afgetrapt in een headless browser in de cloud. Als ook maar één test faalt, weigert het versiebeheersysteem de code samen te voegen. Door te investeren in TDD en geavanceerde tools zoals Playwright, creëert u een ‘fearless’ development cultuur waarin ontwikkelaars met vertrouwen dagelijks tientallen complexe wijzigingen naar productie kunnen pushen. Meer over kwaliteitscontrole vindt u op AG Connect.
Volgende: Svelte en SvelteKit: Waarom Compile-Time Reactivity de Virtual DOM Verslaat
