Testing, test cases and Mock
ApiGo provides three layers of verification, answering respectively "does it work this time", "will future changes cause regressions" and "how do we integrate when dependencies are not ready":
| Capability | Purpose | Data persisted | Applicable environment |
|---|---|---|---|
| Online testing | Sends one request using the current editor content and shows the response and execution trace | No | During development |
| Test cases | Saves a request snapshot and expected result for single-case replay at any time | Yes (per API) | dev |
| Mock rules | Replaces real execution with a fixed response for frontend/caller integration | Yes (separate cache) | dev isolated entry |
Test cases and Mock rules both depend on a saved API. If the API has not been saved, the page shows "Please save the API first".
Online testing
Entry point and prerequisites
After configuring an API in a development-mode workbench, click the "Test" button in the right panel to open the test dialog. The dialog title is "Test: API name".
Online testing uses the SQL, proxy configuration or orchestration rules currently in the editor directly; you do not need to save or release first. This suits verifying as you edit.
Building a request
The top of the dialog is split into tabs by location, showing only the parameters the current API actually supports:
| Tab | Content |
|---|---|
| Header | Request header key-value pairs, added row by row |
| Query | Query parameter key-value pairs; pagination parameters are appended during testing |
| Path | Path parameters, mapped by parameter name and target name |
| Body | Request body, entered according to the API's Body mode |
How the Body is handled depends on the mode:
- JSON: Must be valid JSON, otherwise it cannot be sent.
- Form / urlencoded: Fill in the parameter table item by item; the form data is assembled automatically.
- No Body: The API does not accept a request body, and the tab shows "This request has no Body".
The request URL bar shows the current API path as a placeholder; click "Send" to run the test.
Viewing the response
The response is shown on the right after sending:
| Information | Description |
|---|---|
| HTTP status | The actual response status code; an error code is shown when execution fails |
| Response time | Milliseconds from sending to receiving the result |
| Response size | Size of the response content in bytes, converted to KB / MB |
| Response body | JSON is formatted automatically; text is shown as-is |
| File response | Binary or download responses show the file name, Content-Type and Base64 content, and can be downloaded |
On success the dialog shows "Test succeeded!"; on failure it shows the error message returned by the backend.
Orchestration execution trace
After a test in orchestration mode completes, an "Execution trace" panel appears below the response area, listing nodes in execution order:
| Field | Description |
|---|---|
| Status | Success, failed, skipped |
| Node | Node name or node ID |
| Iteration | Which iteration of a loop node |
| Time offset | Millisecond offset relative to the start of this test |
| Input / output snapshot | Expand to view the node's input and output JSON |
The trace helps pinpoint "which node did not run", "which loop iteration failed" and "which conditional branch was taken". Branch nodes that were not entered are marked as "skipped".
Online testing calls the execution engine directly from the admin side, bypassing the gateway's authentication, rate limiting, caching and logging chain. It verifies whether the API itself executes correctly; gateway governance must be verified with real calls to released APIs.
Test cases
A test case freezes a request into a repeatable assertion, ideal for regression checks after API changes.
Managing test cases
Click "Test cases" on the right side of the development workbench to open the drawer. The list is sorted by update time in descending order:
| Column | Description |
|---|---|
| Case name | A recognizable name |
| Enabled | Enabled / disabled status |
| Expected status | Expected HTTP status code |
| Last result | Not run, success, fail |
| Last run time | Time of the previous run |
| Actions | Edit, run, delete |
Test case fields
| Field | Required | Description |
|---|---|---|
| Case name | Yes | Cannot be empty |
| Expected HTTP status | No | 100–599, default 200 |
| Expected assertion | No | The case passes when the response content contains this string; may be empty |
| Request Header JSON | No | JSON object, defaults to {} |
| Query parameter JSON | No | JSON object, defaults to {} |
| Path parameter JSON | No | JSON object, defaults to {} |
| Request Body | No | Valid JSON; may be left empty when there is no Body |
| Enabled | No | Disabled cases are excluded from regression |
The four request fields are validated for valid JSON before saving; if invalid, the message "Request parameters must be valid JSON" appears.
Execution and verdict
After you click "Run", the platform calls the runtime directly to replay the case. The verdict rules are:
- The actual HTTP status must equal the "expected HTTP status".
- If an "expected assertion" is provided, the response body JSON must contain that string.
- If both are satisfied the result is success; otherwise it is fail, recorded as "response status or assertion mismatch".
The result is written back to the case's "last result" and "last run time", and a response body snapshot is saved. Exceptions thrown during execution also count as fail, with the error message recorded in the last result.
Test cases have a fixed envCode of dev and do not apply to other environments. After releasing to test/production, verify with real calls or external automation tools.
Saving a case from an online test
After a successful online test, click "Save case" to have the platform save the current request's Header, Query, Path and Body plus the response status as a default case named like "API name default case". The case can then be edited and replayed in the test cases drawer.
Mock rules
Mock replaces real execution with a fixed response, suited to scenarios where the database is not ready, third-party APIs are unstable, or the frontend needs to integrate ahead of time.
Isolated entry
Mock only serves a dedicated isolated entry and does not occupy the official API path:
/mock/{envCode}{apiPath}
For example, if the API path is /user/detail, the Mock address in the dev environment is /mock/dev/user/detail. The workbench drawer shows this address directly.
Calling the Mock entry requires:
- A valid
X-AppKeyin the request header; - The application to be enabled.
If the credential is missing or the application is disabled, the gateway returns HTTP 401 with an error code and never enters the official API chain.
Rule fields
| Field | Description |
|---|---|
| Enabled | Switch; a disabled rule is excluded from matching |
| Priority | 1–9999, default 100; lower numbers match first |
| Method | Taken from the API's request method |
| Path | Taken from the API's path |
| Status code | 100–599, default 200 |
| Delay | 0–60000 ms, default 0; delays only the Mock response |
| Response header | JSON object, e.g. {"Content-Type":"application/json;charset=UTF-8"} |
| Response body | JSON content; if left empty, the default preview response is used automatically |
Clicking "Use default response preview" generates an example from the API's response parameter definitions:
- Prefer the parameter's "example value";
- Otherwise use the "default value";
- If neither exists, generate by type: numbers as 0, booleans as false, arrays as
[], objects as{}, strings as empty strings.
Matching order
The gateway filters rules by the following conditions:
- The rule is enabled;
- The environment code matches;
- The request method matches;
- The request path exactly equals the rule path; if the rule has an Ant-style matching expression configured, the expression is used instead;
- When multiple rules match, the one with the lowest priority value wins; an empty priority is treated as the lowest.
Saving a rule change refreshes the gateway cache; the gateway also keeps a 30-second local cache, so old rules may be read for a very short period.
Release restrictions
An API with Mock enabled can only be used for development-environment integration. Syncing it to another environment is rejected with the message:
The API has Mock data enabled and can only be released to the development environment for integration. Turn off Mock before syncing to the target environment
Therefore all Mock rules for the API must be disabled before going live.
Usage recommendations
- Keep Mock response bodies valid JSON so the frontend can parse them using the official structure.
- Use multiple rules to cover different paths or scenarios for the same API, and control fallback rules through priority.
- Mock only validates the caller and the contract, not the SQL, proxy or orchestration logic; real logic still needs online testing and test case coverage.
- Mock rules are not included in official release snapshots and are not synced to other environments.
FAQ
| Symptom | Possible cause | Resolution |
|---|---|---|
| Clicking test cases / Mock asks you to save the API first | The API is still an unsaved temporary tab | Save the API first |
| The Body cannot be sent in online testing | Invalid JSON | Fix the JSON or switch to form mode |
| The case fails while the API passes online testing | The expected status or assertion does not match | Check the expected status, assertion string and response body |
| Mock returns 401 | Missing X-AppKey or the application is disabled | Send a valid application credential and confirm the application is enabled |
| Mock is not hit and the real API is called | The environment, method or path differs, or the rule is disabled | Check the isolated address, request method and rule status |
| Syncing to the test environment is rejected | The API still has enabled Mock rules | Disable all Mock rules and retry |
| A node is missing from the orchestration trace | The conditional branch was not taken or the node was skipped | Expand the trace to confirm the branch and "skipped" status |