Lesson 6 of 6
From manual calls to reusable API tests
10 min
Listen to this lesson
A request that worked once in your client is a note, not a test. A test runs again tomorrow, on another system, with other data, without you, and tells the truth about the result. At Contoso, Ravi's automation portfolio counts about 30 API checks out of 240 automated regression tests; each one started as a manual call. This lesson is the checklist for turning a call into a test, whatever tool runs it.
Five changes that make a call a test
| Manual call | Reusable test |
|---|---|
| Host, client and user typed into the URL | Environment variables: one set for sandbox, CMQ client 100, CMR client 100 |
| Token copied by hand from a previous response | A setup step that fetches the CSRF token and keeps cookies |
| Data typed into the body | Data from a file or a test data recipe, one row per case |
| Eyeballing the response | Assertions on status, structure and business values |
| Whatever data is left behind | Setup and cleanup that restore a known state |
The differences between a call and a test.
Assertions that matter
- Status: the exact code expected (201, not "2xx").
- Structure: required properties present, with the expected types; compare against a stored metadata snapshot to catch service changes after an upgrade.
- Business values: the sold-to party, amount and currency on sales order 1000457; the role on business partner 17100001.
- Side effects: after a write, read back; for interfaces, check the follow-on document or IDoc.
- Negative cases: missing token gives 403, stale ETag gives 412, invalid value gives 400 with the expected message.
What belongs at the API level
| Check | API test | UI test |
|---|---|---|
| Service available, authorized, returns the right data | Best fit: fast and precise | Slow and indirect |
| Validation rules and error messages from the backend | Good fit with negative data rows | Needed once to see the message reaches the user |
| Interfaces from partners and other systems | Best fit: same entry point as production | Not applicable |
| Field layout, navigation, app behavior | Not applicable | Best fit |
| Test data setup for UI tests | Best fit: create data through APIs | Slow and brittle |
Deciding where a check belongs; course <a href="/academy/sap-tau-203">sap-tau-203</a> covers API automation strategy in depth.
Data-driven design
Keep the request generic and the data in a table. The same address-creation test can run for a fleet customer, an aftermarket customer and a one-off customer by changing the row, not the request. Wei's test data recipes provide stable keys in CMQ and CMR; a test that needs a fresh document creates it in setup and records its key. Never hard-code a document number that a refresh will change.
| Case | Business partner | Country | Expected status | Expected message |
|---|---|---|---|---|
| Valid US address | 17100001 | US | 201 | None |
| Missing postal code | 17100001 | US | 400 | Postal code required (text varies by release) |
| Unknown partner | 99999999 | US | 400 or 404 | Partner does not exist |
| Second ship-to depot | 17100006 | US | 201 | None |
Illustrative course data: one request, four rows of data and expectations.
Secrets, evidence and the pipeline
Credentials live in the runner's secret store or environment, never in shared collections, test data files or screenshots. Evidence for each run records the request with secrets removed, the response, the system and client, the time and the result, and goes to SAP Cloud ALM with the test case it belongs to. Ravi's pipeline runs the API checks after each transport import into CMR, so a broken service shows up before the business regression starts.
- Day 1Manual callWorks in the sandbox and in CMQ
- Day 2ParameterizedEnvironment variables, token setup, data file
- Day 3AssertedStatus, structure, business values, negative cases
- Day 4Self-cleaningSetup and cleanup; runs twice in a row with the same result
- Day 5In the pipelineRuns after imports into CMR; evidence in SAP Cloud ALM
Plan for maintenance from the start. Keep the saved $metadata of every service the suite uses, and after each SAP upgrade or feature pack compare it with the new one before running the suite: added properties are usually harmless, removed or retyped ones break tests and interfaces alike. Released APIs on the Accelerator Hub also carry a state (for example active or deprecated) and a successor when SAP replaces them; a deprecated API in your suite is a work item for the next release, not a surprise in the one after.
What would you do?
Ravi reviews a new API test from a contractor. It passes reliably in CMQ. The request URL contains the CMQ host and client 100, the body contains business partner 17100001 and a hard-coded address ID, and the only assertion is status 2xx. CMR is refreshed quarterly from production. What is the most important change before it joins the regression set?
- Parameterize environments, automate the token step, and drive data from files or recipes.
- Assert exact status, structure and business values, plus negative cases.
- Setup and cleanup make tests repeatable; never hard-code refreshed document numbers.
- Keep secrets out of collections; store evidence with the test case.
Check your understanding · not graded
Lesson check
1. Why store host and client as environment variables?
2. What is the weakness of asserting only "status 2xx"?
3. Where should API credentials live?
4. What proves a write test is repeatable?