Testen beheersen: JUnit, Mockito en integratietesten · Les

Eerst tests schrijven

Oefen met het schrijven van falende tests die het gewenste gedrag definiëren voordat u productiecode implementeert.

Les 2 van 411 stappen

Eerst tests schrijven is een gratis Testen beheersen: JUnit, Mockito en integratietesten-les op CoddyKit. Dit is les 2 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Testen beheersen: JUnit, Mockito en integratietesten. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Testen beheersen: JUnit, Mockito en integratietesten bevat in totaal 4 lessen.

De fase 'Red' van TDD

Welkom bij de kern van Test-Driven Development (TDD)! In deze les behandelen we de cruciale eerste stap: eerst een falende test schrijven.

Dit wordt vaak de fase 'Red' van de TDD-cyclus genoemd, omdat je bij het uitvoeren van je tests een 'rode balk' verwacht die een fout aangeeft.

Waarom eerst testen?

Het kan tegenintuïtief voelen om een test te schrijven voor code die nog niet bestaat of nog niet volledig is geïmplementeerd. Toch biedt deze aanpak grote voordelen:

Helderheid: Je wordt gedwongen na te denken over wat de code moet *doen* voordat je nadenkt over *hoe* je dat doet.
Bewijs van falen: Je bewijst dat je test correct werkt door te laten zien dat hij kan falen. Als hij zonder code slaagt, kan je test gebrekkig zijn!
Focus: Je krijgt een duidelijk, direct doel: deze ene test laten slagen.

Tests als specificaties

Zie je falende test als een nauwkeurige specificatie of een mini-vereiste. Hij beschrijft specifiek gedrag dat je toekomstige code moet vertonen.

Hij definieert de invoer.
Hij definieert de verwachte uitvoer of uitkomst.
Hij is concreet en uitvoerbaar.

Dit helpt misverstanden te voorkomen en zorgt ervoor dat je code precies levert wat nodig is voor dat specifieke scenario.

Scenario: eenvoudige rekenmachine

Laten we oefenen door een eenvoudige Calculator-klasse te bouwen. Voor ons eerste stukje functionaliteit willen we dat deze twee getallen kan optellen.

Ons doel is een test te schrijven voor een add-methode die faalt voordat we zelfs maar de juiste implementatie van add hebben geschreven.

De falende test ontwerpen

Voordat we code schrijven, denken we na:

Welke invoer? We tellen 2 en 3 op.
Welke uitvoer? We verwachten dat het resultaat 5 is.
Welke methode? Een methode met de naam add op een Calculator-object.

We schrijven een test die calculator.add(2, 3) aanroept en controleert of het resultaat 5 is.

Cod demonstratie: de falende test

Hier zie je een gesimuleerd voorbeeld van eerst een test schrijven. Merk op dat de add-methode van Calculator opzettelijk onjuist is (de methode retourneert 0). Hierdoor faalt onze 'test', waarmee de fase 'Red' wordt gedemonstreerd.

Voer deze code uit om de gesimuleerde fout te zien!

public class Main {
    public static void main(String[] args) {
        System.out.println("Running a simulated test...");
        Calculator calculator = new Calculator();

        // Our test scenario: 2 + 3 should be 5
        int expected = 5;
        int actual = calculator.add(2, 3);

        if (expected == actual) {
            System.out.println("Test PASSED: 2 + 3 = " + actual);
        } else {
            System.out.println("Test FAILED: Expected " + expected + " but got " + actual);
            System.out.println("This is our 'Red' phase!");
        }
    }
}

// The production code (intentionally incorrect for 'Red' phase)
class Calculator {
    public int add(int a, int b) {
        return 0; // Wrong implementation to make the test fail
    }
}

De 'Red'-fase analyseren

Na het uitvoeren van de vorige code zag je het bericht 'Test FAILED'. Dat is precies wat we wilden!

Verwacht: 5
Werkelijk: 0

Deze fout bevestigt twee dingen: onze test is correct geschreven en de productiecode (de add-methode) voldoet nog niet aan het gespecificeerde gedrag.

De mentaliteit van 'minimale code'

Zodra je een falende test hebt, is de volgende stap in TDD (de fase 'Green') het schrijven van de *eenvoudigst mogelijke code* om die test te laten slagen.

Ontwerp niets te ingewikkeld.
Voeg geen extra functies toe.
Richt je alleen op het laten slagen van de huidige falende test.

Zo blijft je code schoon en doelgericht, terwijl je de functionaliteit stap voor stap opbouwt.

Voordelen van eerst testen

Het toepassen van de fase 'Red' van TDD leidt tot:

Beter ontwerp: Tests sturen je naar modulairdere en beter testbare code.
Meer vertrouwen: Elke geslaagde test geeft je vertrouwen in de juistheid van je code.
Minder fouten: Problemen worden vroeg opgespoord, voordat ze ingewikkelde problemen worden.
Levende documentatie: Je tests dienen als actuele voorbeelden van hoe je code moet worden gebruikt.

Korte controle over TDD Red

Laten we controleren of je de fase 'Red' van Test-Driven Development begrijpt.

Beantwoord dit in de interactieve les

Samenvatting: de fase 'Red'

Je hebt de cruciale eerste stap van TDD onderzocht: een falende test schrijven.

De fase 'Red' betekent dat je een test schrijft die faalt.
Deze test fungeert als een duidelijke specificatie voor nieuwe functionaliteit.
Als je ziet dat de test faalt, bevestigt dat de geldigheid ervan en dat de code nog niet correct is.
Deze methodische aanpak leidt tot duidelijkere vereisten en robuustere code.

Hierna leer je hoe je die falende test laat slagen – de fase 'Green'!

Gratis beginnen

Leer Testen beheersen: JUnit, Mockito en integratietesten met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen: 12
Lessen: 48

Gratis beginnen met leren Bekijk de volledige cursus

Veelgestelde vragen

Is de les “Eerst tests schrijven” gratis?

Ja — je kunt hier op het web alle 3 lessen van het leerpad Testen beheersen: JUnit, Mockito en integratietesten, waaronder “Eerst tests schrijven”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus Testen beheersen: JUnit, Mockito en integratietesten bevat in totaal 4 lessen.

Wat leer ik in “Eerst tests schrijven”?

Oefen met het schrijven van falende tests die het gewenste gedrag definiëren voordat u productiecode implementeert. Je oefent met Testen beheersen: JUnit, Mockito en integratietesten door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met Testen beheersen: JUnit, Mockito en integratietesten te beginnen?

Ervaring vooraf is niet nodig. Testen beheersen: JUnit, Mockito en integratietesten op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 2 van 4.

Hoe lang duurt de les “Eerst tests schrijven”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over Testen beheersen: JUnit, Mockito en integratietesten?

Ja. Elke les over Testen beheersen: JUnit, Mockito en integratietesten bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

← Terug naar Testen beheersen: JUnit, Mockito en integratietesten