Skip to main content

Validation And Testing

Use this page as a practical test loop for Zerq workflows before and after publish. The goal is to prove both happy-path and deny/error branches with evidence in logs.

Test matrix to run every publish​

  • Auth: valid token (200), missing token (401), wrong audience/scope (403).
  • Method/profile: allowed method succeeds, blocked method returns 405, wrong profile returns 403.
  • Input validation: schema-valid payload routes valid; malformed payload routes invalid.
  • Rate and resilience: sustained load eventually triggers 429; upstream fault routes error.

Required test inputs​

  • Published collection + proxy revision under test.
  • Test identities for at least two client entries and two profile values.
  • Headers: X-Client-ID, X-Profile-ID, and Authorization.
  • Expected branch/output contract for each node boundary.

Validation steps​

  1. Send a baseline request that should succeed for the expected collection and proxy.
  2. Repeat the same request with a different X-Profile-ID to confirm profile isolation.
  3. Remove or alter Authorization and confirm the deny path returns 401 or 403.
  4. Burst requests to confirm throttling behavior and watch for 429 when limits are exceeded.
  5. Review request logs and audit logs to confirm actor, client, profile, and policy decision.

Example: validating valid vs invalid​

# valid payload -> expected 200
curl -i https://gateway.example.com/payments \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-Client-ID: acme-mobile" \
  -H "X-Profile-ID: partner-prod" \
  -H "Content-Type: application/json" \
  -d '{"amount":1250,"currency":"USD"}'

# invalid payload -> expected 400 with invalid branch evidence
curl -i https://gateway.example.com/payments \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-Client-ID: acme-mobile" \
  -H "X-Profile-ID: partner-prod" \
  -H "Content-Type: application/json" \
  -d '{"amount":"bad"}'

Release gate​

Promote only when request logs prove the expected branch (success, error, valid, invalid) for each test case and audit logs capture who published the revision.

Validation depth limitation​

Current workflow validation endpoints verify workflow payload presence and basic structure, but they do not guarantee every runtime branch will execute successfully. Continue using scenario tests (success, deny, malformed input, upstream failure) before publish.