Generating tests

Test generation is where Joule saves the most time and where it can do the most quiet damage. A generated test suite that passes looks like evidence. If the tests assert the wrong things, or nothing meaningful, it's false evidence. This lesson covers how to generate ABAP Unit and CDS tests with Joule and how to turn weak generated tests into strong ones. It builds on sap-abp-205, which teaches ABAP Unit and test doubles.

ABAP Unit test generation: scope and starting points

SAP's help says you can generate ABAP Unit tests for public, protected and private methods of global ABAP classes, and for public methods of local classes inside global class pools. In ADT for Eclipse you start from the Project Explorer, the Outline view or the ABAP Coverage view: select a method, open the context menu and choose Joule > Generate Unit Tests. The ABAP Unit chat opens. Choose Add Tests to an existing test class or a new one. When the code appears, you can Apply it (and review the differences before finishing), Insert it at the cursor, or Copy it.

The ABAP Unit chat offers more: dependency analysis to find what the code under test depends on, test double support to isolate those dependencies, test code explanations, refactoring of generated test code, and splitting test classes and test methods. Freestyle prompts let you set style rules, such as "Use inline declarations".

SAP's own principles

SAP's Test Generation page lists principles that read like a senior developer's advice:

• Understand the problem domain: Joule doesn't know what the tested code should do. You do.
• Start small: one to three productive methods at a time, for less code and better quality.
• Review and decide carefully: check that tests match the specification; keep them only if they do.
• Customize with prompts: ask for your conventions, and Joule follows the style of existing tests when it adds new ones.
• Run the whole suite after every change, production or test code, and fix failing tests before moving on.

CDS unit test generation

For CDS entities, J4D offers an AI-assisted CDS Unit Test Class Generator. It builds on the CDS Test Double Framework, which creates updatable test doubles for each dependency of the CDS entity under test so you can insert test data and check the entity's logic without touching real tables. SAP describes the result as basic test coverage. For a view such as Contoso's deposit-per-customer view, that means a generated class that inserts agreements and items into doubles and checks the totals. You then add the cases that matter: closed agreements, zero quantities, a customer with no agreements.

When Joule proposes test doubles, it uses the frameworks SAP provides for ABAP Unit: the ABAP SQL Test Double Framework for database reads in ABAP SQL, the CDS Test Double Framework for CDS dependencies, and the ABAP OO Test Double Framework for interfaces. For RAP code, SAP also documents transactional buffer doubles and mock EML APIs. Check that the doubles Joule adds match what the code really depends on: a double for a table the code no longer reads is harmless noise, but a missing double means the test still reads real data in CMD and will break when that data changes.

From weak to strong: a worked example

Joule generated this test for ZCL_CMC_CORE_DEPOSIT, whose rule is a deposit of 45.00 USD per unit:

It passes, and it would still pass if the class returned 1, or 449, or a negative number. The fix is to assert the business rule and to add the edge cases the rule implies: