ACCESS TO IT INTEL GRANTED

Verify request journal assertions before tearing down mocks

TARGET_ENV: WireMock 3.x on Ubuntu 22.04, Debian 12 (jq 1.6+, curl 7.81+)
[ TAGS: wiremock, snippet, verification, request-journal, jq, integration-testing ]

This snippet queries the WireMock admin request journal to assert that a specific endpoint was called exactly the expected number of times, then fails the pipeline if the count diverges. The /__admin/requests endpoint returns every received request with matched stub metadata, and jq filters by urlPath and counts matches. WireMock keeps the journal in memory (bounded by --max-request-journal-entries) and records the match status of each request against the loaded stubs.

This pattern is the backbone of verification-style mocking: instead of only asserting your client's return value, you prove that it issued the correct outbound calls. Production teams embed this in integration test teardown, in contract tests that assert retry counts after a fault, and in audit checks that a scheduled job actually emitted its webhook. It catches silent regressions where a refactor accidentally drops a call while tests still pass.

Security-wise the journal exposes full request payloads including headers, so treat the admin port as sensitive and never expose it to untrusted networks. Performance: journals grow linearly with traffic and can exhaust heap on long-running instances, so set --max-request-journal-entries and reset via DELETE /__admin/requests between test cases. Common pitfalls: forgetting to reset the journal between tests causes cross-test contamination, and counting matched versus unmatched requests requires the wasMatched field, not a naive length check.

> System.Execute()

COUNT=$(curl -sS http://localhost:8080/__admin/requests \
  | jq '[.requests[] | select(.request.urlPath == "/api/orders" and .wasMatched == true)] | length')

if [ "$COUNT" -ne 3 ]; then
  echo "Expected 3 matched calls to /api/orders, got $COUNT" >&2
  exit 1
fi

curl -sS -X DELETE http://localhost:8080/__admin/requests

> Architecture & Security Context

Verified for Valters IT Hub. When deploying this configuration in a production homelab or enterprise environment, ensure that you monitor system resources and implement strict access controls. Administrator privileges are required.


ID: VALTERSIT-B59360588E24

← BACK_TO_VAULT → CVE_DATABASE