Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 5 of 5

Testing advanced behavior

10 min

Listen to this lesson

0:00 / 25:29

Draft, feature control, authorization, side effects and events all add behavior that a simple "create and read back" test never touches. Priya's test strategy for the agreement app splits the work: developers prove BO behavior with ABAP Unit, testers prove the UI and the end-to-end flows in CMQ, and both feed the evidence for sign-off. This lesson shows what to test where.

Testing the BO with ABAP Unit and EML

SAP's RAP unit testing tutorial shows the pattern: a test class declared FOR TESTING RISK LEVEL HARMLESS DURATION SHORT, linked to the behavior definition with an ABAP Doc "! @testing BDEF:... comment; CDS test doubles for the BO's views and SQL test doubles for the tables it touches, created in class_setup; doubles cleared and filled in setup; tests that call the BO with EML (MODIFY ENTITIES, COMMIT ENTITIES) and assert results, failed and reported; and ROLLBACK ENTITIES in teardown. With the test relation, running tests on the behavior definition runs these tests too.

A RAP BO unit test drives the BO through EML against test doubles and asserts on failed and reported as well as on data.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-303
BehaviorHow to test it with EMLContoso test
Draft lifecycleCreate or edit with %is_draft on, change, then EXECUTE Activate; check active data and that Prepare's validations fireActivating an agreement with a negative deposit rate fails with a message and leaves the draft
Instance feature controlGET PERMISSIONS for an instance, or attempt the operation and check failedA CLOSED agreement reports update and delete as disabled
Global feature controlAs above, with the global condition set through an injected dependencyCreate is disabled inside the freeze window
AuthorizationRun the operation with restricted authorizations using SAP's authority check test helper where classic checks are usedA user without 1910 authorization cannot update an Alternadores agreement
DeterminationsModify the trigger field and read back the calculated fieldQuantity 12 at 45.00 gives DepositAmount 540.00
EventsTest the payload-building and the handler logic as separate units; verify delivery end to end in CMQThe handler creates exactly one refund request even if called twice

What to test for each advanced RAP feature. Unit tests isolate the BO; end-to-end runs prove integration.

Testing code that consumes a RAP BO

Code that calls the agreement BO, such as the refund event handler or a report, has the BO as a dependency. SAP provides two doubles for that: the transactional buffer double (CL_BOTD_TXBUFDBL_BO_TEST_ENV), which replaces the BO's transactional buffer so EML from the code under test works against test instances, and the mock EML API (CL_BOTD_MOCKEMLAPI_BO_TEST_ENV), which lets the test configure what specific EML reads and modifications return. Both are created with the behavior definition as a dependency.

Code that consumes the agreement BO is tested with one of two BO doubles, both created with the behavior definition as a dependency.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-303
End-to-end in CMQMaria's team: edit, close and refund flows in the Fiori app, with events delivered to finance and the portal
UI and service checksSide effects, greyed-out actions, draft messages in the Fiori elements app; service metadata review
BO tests with EMLDraft, features, authorization, determinations and validations with CDS and SQL test doubles
Consumer testsEvent handler and reports with the transactional buffer double or mock EML API
Test layers for an advanced RAP BO, from isolated unit tests up to end-to-end flows.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-303

What ABAP Unit cannot show

  • Side effects: they are UI annotations. Test them in the app (does the deposit amount refresh?) or with UI automation that follows a Fiori elements pattern, using SAP's own UI test frameworks or generic page-object approaches.
  • Lock timing and resume across sessions: realistic only with real users or sessions in CMQ.
  • Event delivery: channels, brokers and remote consumers are configuration and infrastructure; test them end to end and check the event monitor.
  • CDS access control: test with real test users who have different authorizations; unit tests built on doubles do not exercise what real users are allowed to see.
  1. Every changeBO unit testsRun on transport release with ATC; failures block
  2. Every build in CMQConsumer tests and UI checksEvent handler doubles; automated UI checks for side effects and permissions
  3. Integration cycleEnd-to-end flowsClose agreement to refund in finance; portal status update
  4. UATBusiness acceptanceMaria's team works real scenarios; Lucía covers Wave 2 agreements for company code 1910
When each kind of test runs on Contoso's path to production.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-303

What would you do?

Kenji's ABAP Unit tests for the agreement BO all pass, with good coverage. In UAT, Maria finds that after closing an agreement the Edit button stays active until refresh. Why did the unit tests not catch it, and what should change?

Key points
  • Test BO behavior with ABAP Unit and EML, using CDS and SQL test doubles and a test relation to the BDEF.
  • Use GET PERMISSIONS, failed and reported to test feature control, authorization and validations.
  • Test code that consumes a BO with the transactional buffer double or the mock EML API.
  • Side effects, lock timing, event delivery and access control need UI and end-to-end tests in CMQ.

Check your understanding · not graded

Lesson check

  1. 1. Which ABAP Doc comment links a test class to a behavior definition?

  2. 2. Which double fits a unit test for code that reads and modifies the agreement BO through EML?

  3. 3. How can a unit test check that a closed agreement cannot be updated?

  4. 4. Why test CDS access control with real test users in CMQ?