Lesson 1 of 6
What to test in a RAP BO and at which layer
11 min
Listen to this lesson
Contoso Motor Co.'s core return agreement app is live in CMQ. Kenji's team built it as a managed, draft-enabled RAP business object, ZR_CMC_CoreAgreement with its item entity ZR_CMC_CoreAgreementItem, the behavior pool ZBP_R_CMC_COREAGREEMENT and the OData V4 UI service ZUI_CMC_COREAGREEMENT_O4. The prerequisite courses showed the BO and named the test doubles. This course is about the code: how to write the tests, which framework to use for which rule, and what Priya, the test lead, should demand before the app moves to CMP.
The first decision is not how to test but where. A RAP BO has several layers, and each layer has a test style that proves it best. Testing everything through the Fiori UI is slow and fragile; testing everything with isolated handler tests misses how determinations and validations interact in the save sequence. A good RAP test suite uses each layer for what only that layer can prove.
The layers and what each test proves
In SAP's terms these are unit tests and integration tests. SAP's RAP100 unit testing tutorial builds a test class that calls the BO with EML, commits, and checks the persisted result against test doubles. The ABAP Unit cheat sheet from SAP adds the narrower style: calling a handler method directly while the RAP BO test double framework replaces the transactional buffer. This course calls the first an EML scenario test and the second a handler unit test.
Mapping behavior to tests
| BDEF element | Contoso example | Primary test | Second test |
|---|---|---|---|
| Validation on save | validateDates: ValidTo must be after ValidFrom | Handler unit test: invalid key in failed, message on ValidTo | EML scenario: COMMIT ENTITIES fails, sy-subrc 4 |
| Determination on modify | setInitialStatus sets Status OPEN | EML scenario: create without Status, read back OPEN | Handler unit test if logic branches |
| Determination on save | calcTotalDeposit sums item deposits | EML scenario: two items, total after commit | Handler unit test for rounding |
| Action | closeAgreement sets Status CLOSED | Handler unit test: result returned, Status CLOSED | EML scenario: action then commit |
| Instance feature control | No update or delete on CLOSED | EML: GET PERMISSIONS, or attempt and check failed | UI check in CMQ |
| Authorization | Only 1910 users change 1910 agreements | Handler test with restricted authorizations | Role test with real users in CMQ |
| Draft and Prepare | Validations assigned to Prepare | EML scenario on a draft instance | Resume across sessions in CMQ |
| Side effects | Quantity refreshes DepositAmount | Not ABAP Unit: $metadata and UI check | UI automation |
Contoso's test map for the agreement BO: every behavior element has a primary test at the cheapest layer that can prove it.
Two phases, two kinds of failure
Remember the RAP split between the interaction phase and the save sequence. In the interaction phase, MODIFY ENTITIES changes the transactional buffer and determinations on modify run. On COMMIT ENTITIES, the save sequence runs: determinations on save, validations in check_before_save, then the actual save. The ABAP keyword documentation is precise about the return code: sy-subrc 4 means the failure happened in the early save phase and the responses are in failed; 8 means the late save phase failed and an explicit ROLLBACK ENTITIES is required.
A common blind spot follows from this. A test that only runs MODIFY ENTITIES and checks failed is empty never runs a single validation, because validations on save fire only at commit. Kenji's code review checklist asks: "Which phase does this test assert?" If the answer is "interaction only", the validations are untested.
What goes wrong in testing
- Testing through the UI only. Maria's team found that closed agreements could still be edited through the API, because nobody tested feature control below the UI.
- No commit, no validation. Tests that stop after
MODIFY ENTITIESpass whilevalidateDatesis broken. - Real data in CMD. Tests that read an agreement someone keyed in months ago fail after a client refresh.
- IN LOCAL MODE everywhere. Calling the BO in local mode from a test skips feature and authorization control, so the test proves less than it seems.
What would you do?
Kenji's team has 14 handler unit tests for the agreement BO, all green, and no EML scenario tests. Priya asks whether that is enough for the build-phase exit. What should she ask for?
- Test each RAP rule at the cheapest layer that can prove it, then cover main paths again in an EML scenario.
- Validations on save run only at COMMIT ENTITIES; a test without a commit does not test them.
- sy-subrc 4 after COMMIT ENTITIES means an early save failure; 8 needs an explicit ROLLBACK ENTITIES.
- Side effects and draft resume are UI behavior: test them in CMQ, not with ABAP Unit.
Check your understanding · not graded
Lesson check
1. Which test proves that determinations and validations work together in the save sequence?
2. A test runs MODIFY ENTITIES and asserts that failed is empty. What has it not tested?
3. What does sy-subrc 4 after COMMIT ENTITIES mean?
4. Where should Contoso test that Quantity refreshes DepositAmount on screen?
5. Why is testing only through the Fiori UI risky for a RAP BO?