Testing generated apps: from generated tests to real evidence

Joule can generate unit tests for CAP application logic, and a coding agent can write more. That's useful, and it's also a trap: tests generated from the code tend to confirm what the code does, not what the business needs. This lesson shows how to use generated tests as a starting point and turn them into evidence a test lead can sign.

Generating tests in SAP Build Code

SAP documents the flow: from the Application Logic Editor, open the code editor for unit tests, agree to enable the test environment, enter a prompt or keep the default, and accept the result. Then, in the Generative AI-Powered Development guide, run the test; the required npm dependencies are installed and the test runs through npm test. The tests use CAP's test support, cds.test, which starts a CAP server for the project and gives you HTTP helpers such as GET and POST, an expect function and data.reset to restore the database between tests. CAP documents it for the Node.js test runner, Jest, Mocha and Vitest.

What generated tests usually miss

Two of these found real bugs in Elena's app. The date comparison treated failure dates as text, so "2025-1-05" style values sorted wrongly when data came from an upload; and the approve handler checked the status but not the user's role, relying on the UI to hide the button. Both fixes came with tests that fail on the old code, which is the simplest proof that a test tests something.

Reviewing tests written by AI

• Read the assertions first. A test with no meaningful assertion, or one that asserts whatever the code returned, proves nothing.
• Watch for rewritten expectations. If the agent changed an expected value to make a test pass, ask why; that's the most common way generated tests hide defects.
• Check the data. Tests that pass only with the sample CSV are fragile; reset and create the data each test needs.
• Break the code on purpose. Comment out a rule and run the tests. If nothing fails, the rule isn't tested.
• Keep tests independent. Use data.reset between tests so order doesn't matter.

Above the unit level

Unit tests with cds.test cover the service. Priya's team still runs end-to-end scenarios in cmc-ext-test against CMQ client 100 through the CMC_S4HANA destination once the app reads customer data from S/4HANA: a claim for Great Lakes Fleet Services, its review and approval, and a rejected claim older than 24 months. For UI-level automated checks of Fiori elements and UI5 apps, SAP's documentation describes OPA5 integration tests; whatever tool runs them, the scenarios and expected results come from the business rules, not from the generated code.

Keep the test data honest. Generated sample data is fine for unit tests, as long as it is invented and its edge cases are deliberate. End-to-end data in cmc-ext-test should come from CMQ client 100's test master data, not from production copies, and claims created there should be cleaned up after each run so tests don't pass because of leftovers from the previous day.