moza-mock

Mocks voor externe API's en MOZa-services, als standalone WireMock.

Structuur

• mappings/ - de stubs: request-matching en responsemetadata (status, headers). Eén stub per bestand, of meerdere stubs per service in een "mappings": [...] array.
• __files/ - de responsebodies waar de mappings naar verwijzen via bodyFileName, per service een submap.
• bruno/ - Bruno-collectie (mocks) met een request per stub. Openen via Open Collection en de map bruno/ kiezen (niet importeren), daarna environment lokaal selecteren. Elk request assert de verwachte statuscode, dus de hele collectie draaien werkt ook als smoketest.

Mock toevoegen of aanpassen

1. Zet de responsebody in de servicemap onder __files/, bijvoorbeeld __files/mijnservice/endpoint-response.json.
2. Maak een mapping in mappings/:

{
  "request": {
    "method": "GET",
    "url": "/api/v1/mijn-endpoint"
  },
  "response": {
    "status": 200,
    "headers": {
      "Content-Type": "application/json"
    },
    "bodyFileName": "mijnservice/endpoint-response.json"
  }
}

Voor bestaande mocks: matching aanpassen doe je in de mapping (url, urlPattern voor regex, method), de body staat in __files/.

Wat wordt gemockt

Externe API's:

• Ondernemersplein: dop-articles.json, dop-subsidies.json
• KVK Handelsregister: handelsregister.json
• SRU officiële publicaties: repo-overheid.sru.json

MOZa-services:

• NMC: nmc.json
• Profielservice: profielservice.json
• Verificatieservice: verificatieservice.json
• Actualiteitenservice: actualiteitenservice.json
• CloudEvents-ontvanger (POST /events): notificatie-events.json

De testdata gebruikt overal dezelfde partij: "Test BV Donald", KVK 68750110, donald@testbv.nl. Dat sluit aan op de handelsregister-mock.

profielservice.json bevat naast de echte API (POST /partij enz.) ook de stubs uit moza-poc-fbs-berichtenbox. Die PoC bevraagt de profielservice via GET /api/profielservice/v1/{identificatieType}/{identificatieNummer} en leest scopes als OIN-identificatie. Let op: geen dienst-object met UUID in die scope-responses zetten, de PoC leest dienst.id als getal.

Foutscenario's

Standaard krijg je het happy path. Met deze waarden (als identificatieNummer, of als padsegment bij het GET-contract) krijg je een andere respons:

Waarde	Waar	Respons
999996915	profielservice partij-lookup (GET en POST)	404
999996915	NMC POST /centraal/notificaties	400
999991401	profielservice partij-lookup (GET en POST)	500
111222333	profielservice partij-lookup (GET en POST)	200, partij zonder voorkeuren
verificatieCode: "000000"	POST /emailverificatie	400
code: "000000"	verificatieservice POST /verify	200 met success: false
999992222	profielservice partij-lookup (POST), POST /contactgegeven, POST /voorkeur	de soft-delete-partij: bevat alleen de opnieuw toegevoegde rijen
5017de1e-0001-4000-8000-000000000001	DELETE/PUT /contactgegeven	404, contactgegeven heeft al een soft delete
5017de1e-0003-4000-8000-000000000003	DELETE/PUT /voorkeur	404, voorkeur heeft al een soft delete
email: "verwijderd@testbv.nl"	POST /emailverificatie	400
email: "verwijderd@testbv.nl"	POST /emailverificatie/code	404
999992223	profielservice POST /contactgegeven, POST /voorkeur	409, contactgegeven/voorkeur bestaat al

Deze stubs hebben een expliciete priority zodat ze winnen van de generieke stub voor dezelfde URL (lager getal wint, default is 5).

Soft delete in de profielservice

Verwijderen in de profielservice is een soft delete: de rij blijft bestaan met een verwijderd_op-tijdstempel, maar verdwijnt uit alle leespaden. Wat dat betekent voor de mock en de collectie:

• DELETE /contactgegeven/{id} en DELETE /voorkeur/{id} hebben geen request body meer en geven 204. Een tweede DELETE op dezelfde id geeft 404: de rij is niet meer vindbaar.
• PUT /contactgegeven en PUT /voorkeur geven 204 in plaats van 200, en 404 op een id met een soft delete.
• Dezelfde waarde opnieuw toevoegen na een verwijdering herstelt de oude rij niet, maar levert een nieuwe rij met een nieuwe id op (201). De unieke indexen zijn partieel (WHERE verwijderd_op IS NULL), dus de verwijderde rij bezet de sleutel niet meer.
• Een e-mailadres met een soft delete is niet meer te verifieren en krijgt geen nieuwe verificatiecode.
• Was het verwijderde contactgegeven of de verwijderde voorkeur de laatste actieve rij van de partij, dan wordt de partij zelf ook soft-deleted: POST /partij geeft daarna 404. Het e2e-contactgegeven-scenario laat dit zien (e2e-stap 8, na het verwijderen van het enige contactgegeven van die partij).
• Een contactgegeven of voorkeur toevoegen is geen upsert meer: bestaat de combinatie (partij, type, waarde) resp. (partij, voorkeurType, scope) al actief, dan geeft POST /contactgegeven of POST /voorkeur nu 409 in plaats van 200.

De stubs hiervoor zijn stateless: ze hangen aan de vaste ids en waarden uit de tabel hierboven, niet aan een WireMock-scenario. De stateful variant (aanmaken, bijwerken, verwijderen) staat in het e2e-contactgegeven-scenario.

Bruno-environments

De collectie heeft per service een url-variabele, met vier environments:

• lokaal, sp, zad: alle variabelen wijzen naar de mock (respectievelijk localhost, het SP-cluster en ZAD).
• Dev omgeving: elke variabele wijst naar de echte service. Let op: POST/PUT/DELETE doen dan echte mutaties, de foutscenario-waarden bestaan daar niet, en de verificatieservice is alleen in-cluster bereikbaar. De KVK-testomgeving vereist een apikey-header; de publieke testkey staat in het environment.

De create-requests zetten het id uit de response in een variabele (contactgegevenId, voorkeurId, referenceId, de voorkeur-ids uit 4-voorkeuren); de bijbehorende update- en delete-requests gebruiken die variabele. Zo ruimt een create gevolgd door een delete zichzelf op, ook tegen de echte services. In de mock-environments staan defaults voor die id-variabelen (de fixture-ids van de mock), zodat een delete of update ook los uitgevoerd kan worden; in Dev omgeving staan die bewust niet.

De map e2e is een end-to-end test over de echte services heen: contactgegeven aanmaken in de profielservice, notificatie versturen via de NMC, e-mailadres bijwerken, opnieuw versturen, en opruimen. Draai de map als geheel (rechtermuisklik, Run) tegen het Dev omgeving-environment, of met bru run e2e --env "Dev omgeving". Tegen de mock-environments slaagt de flow ook: voor BSN 999993653 heeft de mock een stateful WireMock-scenario (aangemaakt, bijgewerkt, verwijderd) met de standaard donald-adressen; een nieuwe create begint de cyclus opnieuw. De scenario-state staat in het geheugen van de mock en kan gereset worden met POST /__admin/scenarios/reset. Let op bij Dev omgeving: e2eEmail en e2eEmailNieuw moeten in NotifyNL gewhitelist zijn, anders geeft de NMC een 500 op het versturen.

Lokaal draaien

podman run --rm -p 8080:8080 `
  -v "${PWD}\mappings:/home/wiremock/mappings" `
  -v "${PWD}\__files:/home/wiremock/__files" `
  wiremock/wiremock:3.13.2

Handig bij het debuggen: /__admin/mappings toont de geladen stubs, /__admin/requests/unmatched de requests die geen stub raakten (met closest match).