Lesson 5 of 5
Testing APIs
9 min
Listen to this lesson
Testing an API behind API Management is not the same as testing the backend service. The proxy adds behavior: it rejects calls, limits them, transforms them and rewrites errors. Every one of those policies can block or alter valid traffic if misconfigured. So the API test has three layers: the backend returns the right data, the proxy passes it through correctly, and the policies behave as designed for good and bad calls.
Three layers to test
Start at the bottom. If the backend returns wrong data, no proxy test will catch it, so the backend service is tested first with the same technical user the provider will use. Then test the proxy with valid calls and compare responses with the contract: field names, types, required fields and status codes. Then test the policies, especially the paths where a call should be refused.
Policy test cases
| Policy | Test | Expected result |
|---|---|---|
| Verify API Key | Call with no key; with an invalid key; with a revoked application's key; with a valid key | Three agreed authentication errors, one success; no backend call for the failures |
| Spike Arrest | Burst above the configured rate from one client | Excess calls rejected with the agreed error; backend load stays within limits |
| Quota | Exceed the quota in a shortened test window, then wait for reset | Calls refused after the limit, accepted again after the reset |
| Threat protection | Oversized or deeply nested JSON body | Rejected at the proxy before reaching S/4HANA |
| Assign Message (backend) | Inspect the request the backend receives | No consumer key, correct backend credentials, no internal headers leaked back |
| Raise Fault and error mapping | Unknown order number; backend down | Agreed error body and status, no raw backend error text |
| CORS | Browser preflight OPTIONS request from the portal's origin | Allowed origin and methods returned; other origins refused |
Policy tests for Contoso's order status proxy. Record the exact status codes your configuration returns.
API Management includes a test console for sending requests to deployed proxies, which is enough for exploratory checks and for confirming a deployment. For repeatable testing, keep a version-controlled collection of requests with expected responses, including the negative cases, and run it after every policy change and before every product publish. Use a test application's key, never a customer's production key.
- Did the change touch a policy, the provider or the target?Yes → rerun the full policy test set for that proxy · No → next question
- Did the backend service change, for example after an S/4HANA support package?Yes → rerun backend and contract tests · No → next question
- Is a product being published or changed?Yes → run the subscription, key and quota tests with a test application · No → smoke test only
Contract and performance
Contract tests compare real responses against the OpenAPI description: every documented field present with the right type, no undocumented breaking changes, and every documented error status reachable. Performance tests measure latency through the proxy at expected and peak volume and show how much time is spent in the proxy versus the backend. Agree target response times with the consumer before testing, so results have a pass mark.
What would you do?
Kenji's team tightened the JSON threat protection policy on a write API. All of Priya's happy-path tests still pass. A week later, a fleet customer's larger orders start failing. What gap in testing does this reveal?
- Test three layers: backend correctness, proxy pass-through and shaping, policy behavior.
- Every policy needs negative tests with recorded status codes and no backend call for refused requests.
- Keep a version-controlled request collection and rerun it after every policy or backend change.
- Contract tests compare responses with the OpenAPI description; performance tests need agreed targets.
Check your understanding · not graded
Lesson check
1. Why must API tests cover policies, not just the backend?
2. What should a call with no API key produce?
3. What does a contract test compare?
4. Which key should be used for repeatable API regression tests?