Quality from day one

The cheapest defect is the one a developer finds before the code leaves CMD. ABAP gives you two built-in tools for that: the ABAP Test Cockpit (ATC), which runs static checks over your code, and ABAP Unit, the unit testing framework built into the ABAP language. SAP's ABAP Cloud guide describes ABAP Unit as the state-of-the-art unit testing framework for ABAP, with test double frameworks for RAP business objects, CDS views and SQL. Using both from your first day is the habit that separates code you can sign off from code you hope works.

ABAP Unit in one minute

Unit tests are methods of a local test class, declared with FOR TESTING. The class declares a risk level (HARMLESS, CRITICAL or DANGEROUS) and an expected duration (SHORT, MEDIUM or LONG), which the system uses to decide whether a test may run. Test methods call the code under test and check results with methods of CL_ABAP_UNIT_ASSERT, such as assert_equals. Fixture methods prepare and clean up: setup and teardown around each test, class_setup and class_teardown once per class. In ADT you run all tests of a class with Ctrl+Shift+F10, and a coverage run with Ctrl+Shift+F11.

ATC in one minute

The ATC runs a check variant, a named set of checks, over objects or packages and reports findings with priorities. Your organization decides which variant applies and which priorities block a transport. For new ABAP Cloud work, the variant enforces cloud rules; for converted code, a readiness variant shows how far it is from ABAP Cloud. SAP's cheat sheet uses the variant ABAP_CLOUD_READINESS for that purpose: run it on a classic class and the findings list what stands between it and ABAP Cloud.

A first test, in words

Suppose Kenji's team writes a method that calculates the core deposit owed on an order: a fixed deposit per alternator, zero for products without a core. A good first test class has three short test methods. One checks an order with two CMC-ALT-100 units and expects two deposits. One checks an order with only CMC-RTR-200 rotors and expects zero. One checks an empty order and expects zero without an error. Each test arranges its data, calls the method once and asserts one result. If the method later reads data from the database, the team will isolate that dependency with a test double so the test does not depend on what happens to be in CMD; later courses in this track show how.

• Name each test method after the behavior it proves, for example two_alternators_two_deposits.
• Keep tests independent: no test should rely on another having run first.
• Assert the result the business cares about, not internal steps.
• Run the tests before every task release, not once at the end.