Self-contained tests

A self-contained test creates the data it needs, uses it, and leaves the system in a known state. It does not depend on what another test or a person did earlier. The ISTQB Test Automation Engineering syllabus (v2.0) describes this use of automation explicitly: test scripts that create test data can be placed in a setup step, and cleanup can follow the run. For SAP the question is not whether to do this, but for which objects and through which interface.

Arrange, act, assert, clean up

ArrangeCreate or find prerequisite data: business partner, product extension, stock, conditions. Record every key created.
ActRun the business step under test through the UI or service, exactly as a user or interface would.
AssertCheck the business outcome: document created, status, amounts, follow-on documents.
Clean upReverse, cancel, block or mark the data so it cannot disturb later runs.
EvidenceWrite the keys, timestamps and results to the log so a failure can be traced.

The shape of a self-contained SAP test.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-302

Contoso's order-to-cash regression test is a good example. The old version opened sales order entry for customer Great Lakes Fleet Services and material CMC-ALT-100 and hoped both were in good shape. The new version first creates a fresh customer through the business partner API with the sales area 1710 / 10 / 00 extension, then confirms the material is sellable and has stock, then runs the order through the Fiori app, the delivery and billing, and finally blocks the test customer for further sales so nobody else uses it.

The rebuilt order-to-cash test arranges its own customer, checks the material, acts through the real UI and then takes its customer out of circulation.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-302

Which interface creates the data

Creating data through the user interface is slow and fragile; that is the very thing you are trying to test, not the thing you want in your setup. Prefer service-level creation. SAP S/4HANA exposes released APIs for most master and transactional data, listed on the SAP Business Accelerator Hub. Common choices include the Business Partner API (API_BUSINESS_PARTNER), the Product Master API and the Sales Order API (API_SALES_ORDER_SRV). For on-premise and private cloud systems, BAPIs such as BAPI_GOODSMVT_CREATE for goods movements are a long-standing alternative. Check which APIs are released for your release and which fields and movement types each one supports before you build on it; some APIs reject fields or movement types they do not support.

Option	Speed and stability	Watch out for
Released OData or SOAP API	Fast, stable contract, versioned	Field and scenario coverage varies by API; needs a technical user with the right roles
BAPI or function module via RFC	Fast, mature, wide coverage on-premise	Commit handling (BAPI_TRANSACTION_COMMIT); not available in the public cloud
Custom data helper (ABAP class)	Fast and tailored	Must be maintained, transported and kept out of production
UI-driven setup	Slow and brittle	Turns every UI change into a setup failure; use only when no service exists

Ways to create prerequisite data, best first.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-302

Hands-on lab · ACCELQ

Create, check and clean up test data with a REST call in a Library Action

A Library Action holds non-UI logic, such as API calls, and can be used anywhere in a Scenario. You'll build a tiny data factory that creates a record through a REST call, reads it back and removes it: the shape of a self-contained SAP test.

Practice on TripPin OData V4 reference service (public, no login; not SAP, but the same OData protocol as SAP's released APIs)

If you haven't set up ACCELQ yet, do the setup lab first.
Open the TripPin link in your browser. It redirects to an address containing (S(...)): a private session with its own copy of the sample data. Copy that full .../TripPinServiceRW/People address.
Click + > Action, choose Library Action (non UI), name it Create test person and click Save & Continue.
In the Logic Editor, click + API > Insert REST call. Paste the session address as a Literal Endpoint URL, set Method POST and a header Content-Type: application/json, then click NEXT.
Choose a JSON payload and enter {"UserName":"auto0412a","FirstName":"Auto","LastName":"Fleet"}, using your own unique UserName that starts with auto. That prefix is your run reference.
Click SEND REQUEST. Expect Status 201. Click the status and the UserName value in the response to turn them into assertions, then click SAVE.
Insert a second REST call: GET on the session address followed by ('your-user-name'). Assert Status 200 and the FirstName value.
Insert a third REST call to clean up: DELETE on the same address with the header If-Match: * (TripPin refuses a delete without it). Assert Status 204.
Click + > Scenario, name it Self-contained test person, add your Library Action as its step, then click Run with your Local Agent and open the Test Report.

Done when The Test Report shows one passed Test Case with three calls: 201 on create, 200 with your FirstName on read-back and 204 on delete. Keep the report link and note the UserName you used as the run reference.

Learn more in ACCELQ’s docs: Library Action · REST API Test Automation in ACCELQ · Verifying API Responses in ACCELQ

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

What not to create inside the test

Some data is too expensive or too risky to create per run. Organizational units, company code settings, plants, pricing procedures, account determination and output configuration are configuration, delivered by transport. Tests should rely on them and check them at the start of a run, not create them. Large master data such as a product with full MRP, costing and valuation views is borderline: creating it is possible but slow, so many teams create one product per release cycle and reuse it, keeping only the transactional data per run.

Reuse and verifyConfiguration and org units: cheap to read, rarely changed. Check at run start.

Shared, owned setRich master data such as fully extended products: create once per cycle and protect.

Create per runCustomers, purchase orders, sales orders: cheap to create and often changed by others.

Pool and replenishStock and open items: costly to create inline, consumed constantly. Lesson 3.

Choosing a data approach by creation cost and volatility.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-302

Make the data unique and traceable

Every record a test creates should carry a run reference: a search term, an external reference field or a naming pattern such as AUTO-<run id>. This lets parallel runs avoid each other, lets cleanup jobs find leftovers, and lets an analyst link a failed test to the exact documents it touched. Avoid encoding meaning in the generated keys themselves; the number range decides the key and you read it back from the API response.

A run reference on every created record does three jobs at once.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-302

What would you do?

Kenji proposes that every regression test creates its own plant and storage location so tests are fully isolated. What is the best response?

Key points

A self-contained test arranges its own data, acts, asserts the business outcome and cleans up.
Create prerequisite data through released APIs or BAPIs, not through the UI under test.
Wrap creation in a reusable data factory so changes are fixed in one place.
Configuration and org units are verified, not created; volatile transactional data is created per run.
Tag every created record with a run reference for isolation, cleanup and traceability.

Arrange, act, assert, clean up

Which interface creates the data

What not to create inside the test

Make the data unique and traceable

Lesson check