Route Change Smoke Testing

This workflow turns 鈥淚 changed routes鈥?into a concrete, repeatable set of smoke tests (what to call, with what auth, and what to verify).

Purpose & Scope

Use this workflow when:

• •You changed route registration, handlers, middleware, or request/response shapes.
• •You need a fast but disciplined verification pass before review/merge.

Out of scope:

• •Exhaustive security testing
• •Large-scale contract redesign (requires explicit human review gates)

Inputs & Preconditions

Inputs:

• •The changed files or a list of changed routes/endpoints
• •Environment base URL and route prefix/mount point
• •Authentication method and test identities
• •Expected side effects (DB writes, logs, monitoring events)

Preconditions:

• •You can reproduce requests in a development/test environment.
• •You know where routes are registered (router mount points and handler code).

Steps

1. •

   Collect candidate route changes

   • •Prefer a deterministic file list:
     • •Use git diff --name-only <base>...HEAD (or equivalent) to list changed files.
   • •Filter to likely route-related files (examples to consider):
     • •**/routes/**, **/*router*, controllers/handlers, middleware, schemas/validation.
2. •

   Enumerate endpoints affected

   • •For each candidate file, identify endpoints by inspecting code/config:
     • •method (GET/POST/PUT/PATCH/DELETE)
     • •path (full path or router-local path)
     • •required auth/permissions (if present)
   • •If needed, search for route registration patterns (examples):
     • •router.get( / router.post( / app.get( / app.post(
3. •

   Resolve the mount point / prefix

   • •Identify where the router/module is mounted.
   • •Record:
     • •BASE_URL (host + port)
     • •PREFIX (mount path)
   • •Construct the final URL as: <BASE_URL><PREFIX><PATH>.
4. •

   Build a smoke test matrix

   • •For each endpoint, record a minimal test record:
     • •method, url, auth requirements
     • •expected status + response shape (high-level)
     • •one valid request example
     • •one invalid request example
     • •expected side effects (if any)

   Example record (shape only):

   json

   {
     "method": "POST",
     "url": "https://example.test/api/v1/widgets",
     "auth": { "type": "bearer", "required": true, "roles": ["admin"] },
     "request": { "valid": { "name": "A" }, "invalid": { "name": "" } },
     "expect": { "status": 201, "response_shape": { "id": "string" } },
     "side_effects": ["db: widgets row created"]
   }
   

5. •

   Execute focused verification

   • •For each endpoint:
     • •Run the happy path test (valid auth + valid payload).
     • •Run one key failure test (no auth 鈫?401/403, or invalid payload 鈫?400).
     • •Verify the declared side effects (DB/log/monitoring) where applicable.
   • •Record what was executed and the observed results in workdocs.
6. •

   Debug failures deterministically

   • •If the route fails with 401/403/404, use the auth route debugging workflow to isolate:
     • •mount/prefix mismatch vs auth mismatch vs guard/permission mismatch.

Outputs

• •A smoke test matrix (stored in workdocs) with reproducible requests and expected outcomes
• •A short test report (what was tested, results, and any fixes performed)

Safety Notes

• •Do not hardcode secrets or real credentials in long-term docs; keep them in workdocs if needed.
• •Do not weaken auth/permission checks without explicit human approval.

Related