Lesson 2 of 5
Layers of automation
10 min
Listen to this lesson
Not every automated test should drive a screen. A check can run against a single ABAP class, against an API, or against the user interface as a user would. Each layer has a different cost, speed and fragility. The test automation pyramid is the classic way to reason about that mix.
The pyramid and its two rules
Mike Cohn described the pyramid in his book Succeeding with Agile: many unit tests at the bottom, fewer service tests in the middle, and few UI tests at the top. Martin Fowler's site summarizes the two rules that matter: write tests at different granularity, and the higher the level, the fewer tests you should have. It adds a practical corollary: push each check as far down as it can go, because every test carries ongoing maintenance cost, and if a high-level test catches a defect that no lower test caught, add the lower-level test.
What sits in each layer for SAP
| Layer | SAP examples | Who usually writes it | Typical speed |
|---|---|---|---|
| Developer unit | ABAP Unit tests for a custom pricing class; unit tests for a CAP service on SAP BTP | Developers (Kenji's team) | Seconds |
| UI component | UI5 QUnit and OPA5 tests for a custom Fiori app, run against a mock server | UI developers | Seconds to minutes |
| Service / API | Call the sales order OData service and check the response; post an IDoc to a test client and check the status | Developers and automation engineers | Seconds per call |
| UI process | Create a sales order for Great Lakes Fleet Services in a Fiori app or VA01, deliver, bill, check accounting | Automation engineers with key users | Minutes per flow |
Typical owners and run times; your team structure may differ.
SAP's own UI5 documentation reflects the same thinking. It shows testing tools along an agile testing pyramid, recommends OPA5 for integration tests because it is part of SAPUI5 and built on QUnit, and states that end-to-end tests are not recommended with OPA because of authentication issues and fragile test data. For true end-to-end browser tests, the UI5 documentation points to browser-driving frameworks that understand UI5 controls rather than raw page elements.
Why SAP pyramids are often upside down
Many SAP programs start with the opposite shape: hundreds of recorded end-to-end UI scripts and almost no unit or API tests. It happens because the people who own regression are business testers, the most visible risk is "the process", and standard SAP code is not the customer's to unit test. The result is slow, fragile suites where one changed screen breaks forty scripts.
- Is the logic custom code you own, such as a pricing class or a validation?Yes → unit test it with ABAP Unit; keep one UI check for the wiring · No → next question
- Can the behavior be observed through an API, IDoc, table or document?Yes → check it at the service layer · No → next question
- Does the risk lie in the UI itself: navigation, field behavior, role-based visibility?Yes → UI component or UI process test · No → reconsider whether it needs automation
- Is it a cross-module business flow the release depends on?Yes → a small number of end-to-end UI process tests, chosen by risk
What would you do?
A new custom validation blocks purchase orders for Lakeside Components when a required certificate has expired. Where should most automated checks for the validation rules sit?
- The pyramid: many unit tests, fewer service tests, few UI tests.
- Push checks as low as they can go; add a lower test whenever a higher one catches something new.
- SAP layers: ABAP Unit and BTP unit tests, UI5 component tests, OData/IDoc/BAPI service checks, UI process flows.
- Inverted SAP pyramids are common and expensive; keep end-to-end UI flows few and risk-based.
Check your understanding · not graded
Lesson check
1. Which rule comes from the test pyramid as Martin Fowler's site summarizes it?
2. What does SAP's UI5 documentation say about OPA5 and end-to-end tests?
3. A high-level UI test catches a pricing defect that no lower-level test caught. What does the pyramid advice suggest?
4. Why do many SAP programs end up with an inverted pyramid?