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

Lesson 1 of 5

Why developer tests

10 min

Listen to this lesson

0:00 / 8:27

Two weeks into user acceptance testing for Contoso Motor Co.'s move to SAP S/4HANA, Maria, the order-to-cash key user, raised a defect: the core deposit on an alternator order for Great Lakes Fleet Services was off by a few cents on every line. The cause was a one-line rounding change in a custom class that calculates fleet core deposits. The developer had tested it by running a sales order by hand in the development system CMD, with one item. The fix took ten minutes. Finding it, reproducing it in the quality system CMQ, re-transporting and retesting took most of a week and involved Maria, Priya the test lead, Kenji the ABAP lead and Sam from Basis.

A ten-minute fix took most of a week because the defect was found four people and two systems away from the code.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-205

That gap is what developer tests close. A unit test is code that calls a small piece of production code (a method, usually) with known input and checks the result automatically. In ABAP, the tool for this is ABAP Unit, a test framework built into the ABAP language and runtime and part of the xUnit family. Tests live next to the code they test, run in seconds, and can be run by anyone, any number of times.

Where defects get expensive

A defect costs little when the person who wrote the code finds it minutes later. Every step it travels after that adds people, waiting and rework: a transport, an import, a test cycle, a defect ticket, triage, a retest and, in the worst case, a production incident with business impact. You do not need an industry statistic to see it; trace any defect from your last project and count the hand-offs.

  1. Developer, minutesKenji runs ABAP Unit in CMD; the failing assertion names the method and the expected value
  2. Transport releaseAn automated check stops the transport; one person, no ticket
  3. Integration test in CMQA tester finds a wrong deposit; defect logged, triaged, assigned, fixed, re-transported, retested
  4. UATMaria finds it in a business scenario; the test cycle slows and confidence drops
  5. ProductionWrong deposits on real invoices; credit memos, customer calls and an urgent change
The same rounding defect, found at five different points. Each step to the right adds people, waiting and rework.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-205

What a unit test is, and what it is not

SAP's own ABAP Unit material uses a few terms worth adopting. The code under test (CUT) is the unit you are checking. A depended-on component (DOC) is anything the CUT needs but you do not want in the test: a database table, a CDS view, a function module, another class, an authority check. A test double stands in for a DOC, and injection is how the double gets into the CUT. A good unit test isolates the CUT from its DOCs so it runs fast, gives the same result every time and fails only when the CUT is wrong.

A good unit test isolates the code under test by injecting doubles for everything it depends on.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-205
Test typeWhat it provesWho runs itTypical SAP tools
Unit testOne method or class behaves as designed, including edge casesDeveloper, on every changeABAP Unit, test double frameworks
Static checkCode follows rules: syntax, security, performance, released API usageDeveloper and transport releaseABAP Test Cockpit (ATC)
Integration testSeveral components, configuration and data work together in a business flowTest team in CMQManual scripts, SAP Cloud ALM test management, eCATT or CBTA in Solution Manager landscapes
User acceptance testThe business can run its process and accepts the resultKey users such as MariaSAP Cloud ALM test plans and manual test cases

Unit tests are one layer of evidence, not a replacement for the others.

User acceptanceFew, slow, business-owned: does the end-to-end process work for the people who run it?
Integration and regressionBusiness flows across modules, configuration and interfaces in CMQ
Static checks (ATC)Rules applied to every object on every release, no execution needed
ABAP UnitMany, fast, developer-owned: every rule in the code, every edge case
A healthy test portfolio: a wide base of fast developer tests under fewer, slower business tests.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-205

What developer tests buy a program

  • Fast feedback: a developer learns about a broken rule in seconds, while the change is still fresh.
  • Safe change: refactoring, upgrades and fixes can be checked against the same tests, so nobody has to remember every edge case.
  • Executable documentation: a test named deposit_rounds_per_line tells the next developer what the code is meant to do.
  • Cleaner test cycles: integration and UAT testers spend their time on business flows, not on arithmetic that a unit test could have caught.
  • Evidence: test results can be part of the quality gate and the sign-off pack.

What would you do?

Grace, the PMO lead, asks Kenji why his team should spend time on ABAP Unit tests when Priya's team already runs integration and UAT cycles in CMQ. What is the best answer?

Key points
  • Defects get more expensive with every step they travel from the developer.
  • ABAP Unit is the xUnit test framework built into the ABAP runtime.
  • Know the terms: code under test, depended-on component, test double, injection.
  • Unit tests are the fast base of the test portfolio, not a replacement for integration or UAT.

Check your understanding · not graded

Lesson check

  1. 1. In SAP's ABAP Unit terminology, what is a depended-on component (DOC)?

  2. 2. Why did Contoso's rounding defect cost almost a week to resolve?

  3. 3. Which statement about unit tests and UAT is accurate?

  4. 4. Which practice does SAP's Clean ABAP guide describe as poor man's testing?