EML Part 5: Testing RAP with EML and Transactional Consistency

📌 KEY POINTS
✅ Test validations with COMMIT ENTITIES — they run only at save.
✅ Isolate with SQL test doubles; ROLLBACK ENTITIES in teardown.
✅ Cover draft, feature control (GET PERMISSIONS) and bulk.
💡 Run tests in ATC / transport release checks.

▶ WHERE WE ARE
You can use EML fluently (Parts 1–4). The last step is using it to verify behavior automatically. Behavior Implementations Part 5 introduced unit tests; this lesson goes further into what to test and how to keep tests reliable.

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHY EML IS THE RIGHT TEST INTERFACE
OData, Fiori and other BOs all end up in the same RAP runtime that EML uses. A test that creates, changes and commits via EML exercises the real behavior — authorization, feature control, determinations, validations, draft — without a UI. Tests are fast, repeatable and run in CI.

━━━━━━━━━━━━━━━━━━━━
▶ 2. A GOOD TEST STRUCTURE

• Arrange: prepare input with %cid; set up test doubles for data the BO reads (e.g. supplier master data).
• Act: one EML operation (or a short sequence) — MODIFY, EXECUTE, COMMIT ENTITIES RESPONSE.
• Assert: FAILED and %fail-cause, REPORTED messages (severity, number, %element), and data read back with READ ENTITIES.
• Teardown: ROLLBACK ENTITIES.

One behavior per test method; descriptive names like "approve_rejected_in_status_new".

━━━━━━━━━━━━━━━━━━━━
▶ 3. WHAT TO TEST — A CHECKLIST

• Each validation: one passing and one failing case, including the message and field.
• Each determination: result correct; idempotent (trigger twice, same result).
• Each action: allowed and disallowed states; result returned; messages.
• Feature control: GET PERMISSIONS returns the expected enabled/disabled values per status.
• Authorization: run with a test user or use test doubles for authority checks where your release supports it.
• Draft: create a draft (%is_draft = mk-on), change it, execute Prepare and Activate; verify the active instance.
• Bulk: 100–500 instances in one call — no failures, acceptable runtime.
• Cross-BO: calls to other BOs are replaced by test doubles, so you test only your own logic.

━━━━━━━━━━━━━━━━━━━━
▶ 4. ISOLATION

• Tests whose save succeeds write to the database. Use the ABAP SQL test double framework (cl_osql_test_environment) to redirect your tables and CDS views to test data.
• For other BOs your code calls, use RAP BO test doubles where your release provides them, or wrap the call in an interface you can replace in tests.
• Never depend on data that happens to exist in the development system.

━━━━━━━━━━━━━━━━━━━━
▶ 5. CONSISTENCY CHECKS WITHOUT SAVING

• COMMIT ENTITIES IN SIMULATION MODE (current releases) runs the save-sequence checks without persisting — useful in tests and in "check only" program runs.
• A determine action (e.g. checkRequest) lets you run validations on demand via EXECUTE without committing.

━━━━━━━━━━━━━━━━━━━━
▶ 6. RUN THEM ALWAYS
Run ABAP Unit with ATC in the transport release check or in CI (gCTS / pipelines), so a failing test blocks the transport.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Take the checklist and write one test per item for the Purchase Request.
2. Add the SQL test double for ZPR_HEAD and ZPR_ITEM.
3. Add a draft test and a bulk test.
4. Include the test class in your ATC check variant.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER THE SERIES
EML as your API, your integration tool and your test harness. Next: Managed RAP builds a complete BO with everything learned so far.

A team discovered a validation that only failed during save because it checked the combination of header and items — but their tests only called MODIFY and never COMMIT ENTITIES, so the validation never ran in tests. Bad data was caught only by users in QAS.
They reworked the test class: every validation test now ends with COMMIT ENTITIES RESPONSE, uses SQL test doubles so successful saves do not pollute the system, and includes draft and bulk cases. The test suite runs in the transport release check. Since then, validation regressions have been caught before transport.

• Tests that only MODIFY and never commit, so validations are never exercised.
• Tests depending on existing data in the development system.
• No teardown with ROLLBACK ENTITIES, so tests influence each other.
• Testing draft only through the UI.
• No bulk test.
• Tests that call real foreign BOs instead of doubles, failing for reasons outside your code.

• Arrange–Act–Assert with EML; commit when save-phase rules matter.
• Isolate with SQL test doubles and BO test doubles.
• Cover validations, determinations (idempotency), actions, feature control, draft and bulk.
• Use simulation mode or determine actions for check-only runs.
• Run tests in ATC and the transport release check.

Questions: "How do you test a RAP BO?", "How do you make sure validations are tested?", "How do you isolate tests from database data?", "How do you test draft?"
Strong answer: EML-based ABAP Unit tests with MODIFY, COMMIT ENTITIES RESPONSE (validations run only at save), assertions on FAILED/REPORTED/READ results, ROLLBACK ENTITIES in teardown; SQL test doubles (cl_osql_test_environment) and BO test doubles for isolation; draft tested with %is_draft and Activate; feature control via GET PERMISSIONS; bulk test for performance; tests run in ATC/transport checks.