Why test below the UI

A Fiori screen, an SAP GUI transaction and an external system calling an API all end up in the same place: the business logic and database of SAP S/4HANA. When the question a test asks is "does the system price, check and post this correctly?", the user interface is often just the slowest and most fragile way to ask it. Tests that talk to services directly run in seconds, do not care about themes or screen layouts, and give precise answers. This course shows how to build them for the three interface styles you will meet in almost every SAP landscape: OData, SOAP and IDoc.

What you gain

• Speed: an OData call that creates a sales order returns in a second or two; the same flow through a UI script takes far longer with logon, navigation and rendering.
• Stability: no locators, no rendering waits, no theme or layout changes. Service contracts change far less often than screens, and released APIs are versioned.
• Precision: the response tells you exactly which field, message class or status went wrong, instead of a screenshot of a red message bar.
• Coverage of interfaces themselves: for integrations (EDI orders, bank files, a dealer portal) the service is the user. Testing it through a UI would test the wrong thing.

What you give up

Service tests do not prove that a user can do the job. They skip the launchpad, role content, field labels, value helps, draft handling and messages on screen. They also skip whatever logic lives only in the UI layer, such as client-side validations in a custom app. And they can give false comfort when the API a test calls is not the one users or interfaces use: a test that creates sales orders through a released API proves little about an inbound EDI channel that uses IDocs and different defaulting.

Assert on business outcomes

The most common weakness in service tests is stopping at "HTTP 201 Created" or "IDoc arrived". A technical success code says the request was accepted, not that the business result is right. Every service test at Contoso ends with a business assertion: the order has the expected net value and status, the IDoc reached a posted status and the sales order exists with the right quantities, the journal entry balances in company code 1710 with the right G/L accounts. This is the same rule as for any SAP test: expected results are written before execution and checked against the documents.