Antwoord.

Automatische tests worden ingedeeld in unit (eenheid), integratie (integratie) en end-to-end (E2E) om de systeemcontrole op verschillende niveaus te dekken.

Achtergrond: Deze indeling ontstond uit de noodzaak om applicaties zowel in delen als in hun geheel te testen. Daarom worden de testlagen onderscheiden:

specifieke functie (unit)
interactie tussen delen (integratie)
het gehele systeem, dat werkt zoals voor de gebruiker (E2E)

Probleem: Fouten ontstaan vaak niet alleen in de logica van een specifieke methode, maar ook op de raakvlakken van componenten of bij de "echte" uitvoering van het hele systeem met externe diensten. Als alles in één hoop wordt gegooid, is het moeilijk om snel een bug te lokaliseren of te begrijpen waar deze precies is ontstaan.

Oplossing:

Unit-tests controleren geïsoleerde code, meestal op het niveau van functies of eenvoudige klassen. In geavanceerdere gevallen worden mocks en stubs gebruikt.
Integratietests verbinden verschillende componenten (bijvoorbeeld, een module en een database) om te zien hoe ze samenwerken.
End-to-end tests (E2E) simuleren gebruikersscenario's — de hele weg "van knop naar resultaat".

Het is van vitaal belang om de testtypen te onderscheiden om:

De kosten van onderhoud te minimaliseren (E2E-tests zijn duur)
Snelle feedback te behouden (unit-tests zijn razendsnel)
Het aantal valse positieven te verminderen

Belangrijke kenmerken:

Een goede verdeling van tests helpt bij het opbouwen van een betrouwbare "piramidale" benadering (testpiramide).
Het mengen van teststijlen leidt tot problemen bij het lokaliseren van bugs.
Een duidelijk begrip van het doel van elke laag leidt tot maximale efficiëntie.

Misleidende vragen.

Kun je integratietests beschouwen als "gewone" grote unit-tests?

Nee, integratietests testen de samenwerking van meerdere componenten, niet alleen individuele functies. Daarbij is het niet altijd mogelijk om mocks te gebruiken — echte diensten communiceren met elkaar.

Moeten alle tests end-to-end (E2E) zijn?

Nee, dit is een dure en complexe aanpak. E2E is alleen nodig voor kritieke gebruikersscenario's; de meeste logica wordt door andere tests gedekt.

Zijn unit-tests altijd snel?

Niet altijd. Soms is het niet mogelijk om de code te isoleren, of is de methode afhankelijk van complexe externe bronnen. In dat geval verliest de test zijn status als unit.

Typische fouten en anti-patronen

Alle tests worden alleen als E2E geschreven, waardoor de feedback extreem traag is.
Verwarring in de lagen: een unit-test begint de database of API aan te roepen, terwijl E2E-tests op mocks zijn gebaseerd.
Alleen unit-tests worden behouden — probleematische bugs op de raakvlakken van componenten worden niet opgemerkt.

Voorbeeld uit het leven

Negatieve case

Het bedrijf heeft alleen de belangrijkste functionaliteit gedekt met E2E-tests — elke wijziging werd 's nachts gecontroleerd, de tests faalden onbetrouwbaar, bugs werden laat ontdekt.

Voordelen:

Echte gebruikersscenario's zijn gedekt.

Nadelen:

Trage feedback.
Lange analyses van de oorzaken van storingen.
Veel valse positieven.

Positieve case

Het team heeft een testpiramide opgezet: onderaan — unit-tests, in het midden — integratietests, bovenaan — alleen de belangrijkste E2E.