---

Werkblad: API Testing & Postman met restful-booker

Wat ga je doen?

Je gaat de API restful-booker verkennen, een testplan opstellen op basis van user stories, een Postman collection bouwen met positieve en negatieve tests, en afsluiten met een load test. Deze API bevat met opzet een aantal bugs — het is de bedoeling dat je die tegenkomt en documenteert, niet dat je je tests aanpast totdat ze slagen.

Stap 0: Server-adres instellen

Het IP-adres van de testserver kan per sessie wisselen. Vraag je docent naar het huidige adres en zet het als variabele in een Postman environment (niet als collection variable), zodat je het maar op één plek hoeft aan te passen en later eenvoudig kunt wisselen tussen bijvoorbeeld een lokale en een klassikale omgeving:

• Maak in Postman een nieuwe environment aan (linksboven bij Environments → +), bijvoorbeeld genaamd "restful-booker".
• Voeg daarin een variabele baseUrl toe met als initial value én current value bijvoorbeeld http://<huidige-ip>:3001 (zonder / aan het einde).
• Selecteer deze environment rechtsboven in Postman, zodat hij actief staat tijdens het uitvoeren van je requests.
• Gebruik in al je requests {{baseUrl}}/... in plaats van het IP-adres direct te typen.

Zo werkt je hele collection nog steeds als het adres verandert — je past dan alleen de environment-variabele aan, en je collection zelf blijft herbruikbaar voor andere omgevingen.

Stap 1: API verkennen

Doe handmatig een paar requests per endpoint om het gedrag te leren kennen, voordat je iets automatiseert:

• GET /ping — health check
• POST /register — een nieuwe gebruiker registreren (wachtwoord moet minimaal 6 tekens lang zijn)
• POST /auth — een token ophalen
• GET /booking — alle booking-ids
• GET /booking/:id — details van één boeking
• POST /booking — nieuwe boeking aanmaken
• PUT en PATCH /booking/:id — boeking bijwerken (volledig / gedeeltelijk)
• DELETE /booking/:id — boeking verwijderen

Let op: voor PUT, PATCH en DELETE heb je een token nodig (via POST /auth), meegestuurd als header Authorization: Bearer <jouw-token>. Je kunt inloggen met het standaardaccount admin/password123, of eerst je eigen account aanmaken via POST /register en daarna daarmee inloggen.

Let ook op: GET /booking/:id heeft op deze server een opzettelijke vertraging van ~3 seconden. Dat is geen bug en geen netwerkprobleem — het is er bewust ingebouwd zodat je het effect goed ziet tijdens de load test in stap 6.

Stap 2: User stories

#	User story
1	Als operator wil ik een health check endpoint zodat ik kan controleren of de API online is.
2	Als nieuwe gebruiker wil ik mij kunnen registreren met een gebruikersnaam en wachtwoord zodat ik daarna kan inloggen en een token kan verkrijgen.
3	Als beheerder wil ik kunnen inloggen met gebruikersnaam en wachtwoord zodat ik een token krijg voor beveiligde acties.
4	Als bezoeker wil ik alle booking-ids kunnen opvragen, eventueel gefilterd op naam of datum, zodat ik snel een boeking kan terugvinden.
5	Als bezoeker wil ik de details van een specifieke boeking kunnen opvragen zodat ik mijn reservering kan controleren.
6	Als gast wil ik een nieuwe boeking kunnen aanmaken zodat ik een kamer kan reserveren.
7	Als beheerder wil ik een bestaande boeking volledig of gedeeltelijk kunnen bijwerken zodat ik gegevens kan corrigeren.
8	Als beheerder wil ik een boeking kunnen verwijderen zodat geannuleerde reserveringen niet blijven staan.

Stap 3: Acceptatiecriteria schrijven

Schrijf voor elke user story minimaal 1 positief en 1 negatief acceptatiecriterium. Gebruik Gherkin (Given/When/Then) of een duidelijke bullet-vorm — overleg met je docent welke vorm gewenst is.

Voorbeeld (user story 6 — boeking aanmaken):

Scenario: Succesvol een boeking aanmaken met geldige data
  Given ik een volledige set geldige boekingsgegevens heb (firstname, lastname,
        totalprice, depositpaid, bookingdates, additionalneeds)
  When ik een POST-request stuur naar /booking met deze gegevens
  Then ontvang ik een 200-response
  And bevat de response een bookingid

Scenario: Boeking aanmaken zonder verplicht veld
  Given ik een set boekingsgegevens heb waarin het veld "firstname" ontbreekt
  When ik een POST-request stuur naar /booking met deze gegevens
  Then verwacht ik een 400-response (Bad Request)

Vul hieronder je eigen criteria in voor de overige user stories:

User story	Positief scenario	Negatief scenario
1. Health check
2. Registreren nieuwe gebruiker
3. Authenticatie
4. Bookings opvragen
5. Boekingsdetails bekijken
7. Boeking bijwerken
8. Boeking verwijderen

Stap 4: Collection bouwen

Bouw een Postman collection met:

• Een folder per user story
• Per request een Tests-script dat het bijbehorende acceptatiecriterium controleert (pm.test(...), pm.response.to.have.status(...), pm.expect(...))
• Collection variables voor herbruikbare waarden zoals token en bookingId (met pm.collectionVariables.set(...) in een test-script)

Stap 5: Uitvoeren en rapporteren

Draai de volledige collection via de Collection Runner. Documenteer per test:

Test	Verwacht resultaat	Werkelijk resultaat	Bug gevonden? (toelichting)

Een falende negatieve test is vaak net zo waardevol als een geslaagde — het betekent dat je een bug in de API hebt gevonden. Beschrijf wat je zag, verander niet zomaar je assertion om de test te laten slagen.

Stap 6: Load test op GetBooking

Gebruik de ingebouwde performance-testfunctie van de Postman desktop-app (niet de webversie):

• Selecteer je collection (of alleen de folder van user story 5, GetBooking) in de sidebar.
• Klik op Run, en kies het tabblad Performance in plaats van Functional.
• Stel het aantal virtuele gebruikers en de testduur in (bijvoorbeeld 10 gebruikers, 1 minuut).
• Start de test en bekijk de real-time metrics: response times, foutpercentage, requests per seconde.
• Noteer je bevindingen: bij hoeveel gebruikers zie je vertraging of fouten optreden? Houd er rekening mee dat GetBooking altijd al zo'n 3 seconden duurt door de opzettelijke vertraging — kijk vooral naar hóe die tijd oploopt naarmate je meer virtuele gebruikers toevoegt, niet naar het absolute startpunt.

Stap 7: Tests via GitHub Actions

Je collection moet uiteindelijk automatisch draaien via GitHub Actions bij elke push, niet alleen handmatig vanuit Postman. Hoe je een workflow opzet, behandelen we klassikaal — zie de slides van je docent. Zorg dat je aan het eind kunt laten zien:

• Een werkende workflow in .github/workflows/ die je collection met Newman uitvoert
• Een groene (of eerlijk gerapporteerde, deels rode) run in de Actions-tab van je repository