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

Lesson 2 of 5

Testing on-stack extensions

10 min

Listen to this lesson

0:00 / 14:24

On-stack extensions run inside SAP S/4HANA: ABAP Cloud development such as RAP business objects and CDS views, key user extensions, and classic ABAP carried over from ECC. The cheapest place to catch their defects is the developer's own automated tests, which run in seconds and need no test system data. Business tests still matter, but they should confirm the process, not discover that a validation was never written.

Three layers of tests

Business-level testsKey users and automated end-to-end tests of the process in the quality system
Integration testsThe extension with real SAP objects, data and authorizations in a shared system
Developer testsABAP Unit with test doubles for CDS entities, database tables and dependencies
Most tests should sit at the bottom, where they are fast and isolated; fewer, more valuable tests sit at the top.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

ABAP Unit with test doubles

ABAP Unit tests live in test classes defined FOR TESTING with a risk level and duration (for example RISK LEVEL HARMLESS DURATION SHORT). Developers run them in ABAP Development Tools. Good unit tests do not depend on whatever data happens to be in the development client. SAP provides test environments that replace dependencies with doubles:

  • CDS test environment (cl_cds_test_environment): creates test doubles for the CDS entities a view or business object reads, so the test controls the data.
  • ABAP SQL test environment (cl_osql_test_environment): replaces database tables accessed by ABAP SQL, including those written by the code under test.
  • Setup and teardown: environments are created once per test class, doubles are cleared and test data inserted before each test, and changes are discarded afterwards.
In a unit test of the core agreement business object, the CDS entities and the persistence table are swapped for test doubles, so the test controls its data.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

Testing RAP business objects

SAP's RAP unit-testing tutorial shows the pattern for a business object. The test class uses the CDS test environment for the BO's CDS entities and the ABAP SQL test environment for dependent tables. A test method calls the BO through EML (MODIFY ENTITIES) to create an instance and execute actions, checks the FAILED, REPORTED and MAPPED results, persists with COMMIT ENTITIES into the doubles, and verifies the stored result. ROLLBACK ENTITIES in teardown discards changes. A test relation in ABAP Doc lets the tests run from the behavior definition.

  1. class_setupCreate CDS and ABAP SQL test environments
  2. setupClear doubles; insert test data (for Contoso, a core return agreement for Great Lakes Fleet Services)
  3. ActMODIFY ENTITIES: create, then execute an action such as approving the return
  4. AssertCheck FAILED, REPORTED and MAPPED; COMMIT ENTITIES; read back and compare
  5. teardownROLLBACK ENTITIES; class_teardown destroys the environments
Anatomy of an ABAP Unit test for a RAP business object.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

What each extension type needs

ExtensionDeveloper testsIntegration and business tests
RAP business object (level A)ABAP Unit through EML: validations, determinations, actions, authorization checksApp test in QAS with real roles; process test end to end
CDS view for analyticsCDS test doubles with edge-case data (empty, multi-currency, cancelled documents)Reconcile totals with a trusted report in QAS
Key user extension (custom field, custom logic)Limited; test the logic through the appField flow through follow-on documents; positive and negative cases
Classic ABAP (level B/C)ABAP Unit where the code allows it; often needs refactoring firstRegression of every process that calls it
Modification (level D)Rarely unit-testableFull process regression after every adjustment

Test responsibilities by on-stack extension type.

Note the pattern: the cleaner the extension, the more of its testing can move down into fast developer tests. Legacy code usually lacks seams for test doubles, so its tests stay at the expensive top layer. That is part of the business case for remediation: rebuilding a level C report on released CDS views makes it both upgrade-stable and unit-testable.

The cleaner the extension, the more of its testing moves down to fast developer tests; legacy code stays at the expensive business layer.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

What would you do?

Kenji's developer delivers the core return agreement app with no ABAP Unit tests, saying "Maria will test it in CMQ." What should Priya ask for?

Key points
  • Put most on-stack tests at the developer layer: ABAP Unit with CDS and ABAP SQL test doubles.
  • Test RAP business objects through EML; check FAILED, REPORTED and MAPPED and the committed result.
  • Key user extensions and legacy code rely more on integration and business tests.
  • Cleaner extensions are easier to unit test, which strengthens the case for remediation.

Check your understanding · not graded

Lesson check

  1. 1. Which SAP class creates test doubles for CDS entities in ABAP Unit?

  2. 2. How does a unit test exercise a RAP business object?

  3. 3. Why use test doubles instead of client data in unit tests?

  4. 4. Which extension type usually needs full process regression after each adjustment?