Testing side-by-side extensions

Side-by-side extensions run on SAP BTP and talk to S/4HANA through APIs and events. They are decoupled from the core by design, which makes them upgrade-friendly, but it moves the risk to the boundary: the API contract, authentication, network and data mapping. Testing them well means testing the app on its own, testing the boundary explicitly, and testing a few real end-to-end flows.

Every arrow between the warranty app and S/4HANA is a boundary the app depends on, which is where side-by-side testing must focus.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

Service tests in CAP

CAP has built-in test support. Developers add the @cap-js/cds-test package and use cds.test to start a CAP server for the project inside the test, then call its services with HTTP helpers such as GET and POST, with mock users for authentication. Tests run with Node.js's built-in test runner or other common JavaScript runners. By default the server uses an in-memory database, and a data reset before each test keeps tests independent. Services can also be called programmatically, without the HTTP layer, to test logic directly.

End-to-end testsA few critical flows against a connected S/4HANA quality system

Contract testsThe app's expectations checked against the API specification and the real API

Service testsCAP services over HTTP with cds.test, mock users and in-memory data

Unit testsPure functions: claim rules, mappings, validations

A test layering for a side-by-side CAP extension.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

Mocking S/4HANA, carefully

To develop and test without a live S/4HANA, CAP lets you import an API definition (for example an EDMX file from the SAP Business Accelerator Hub) with cds import. During local development CAP mocks imported services automatically, running them in-process with the app's in-memory database, or in a separate process with cds mock. That makes the inner development loop fast and lets the integration logic be built in parallel. The CAP documentation also warns against overdoing it: the more you mock, the less you test the real thing.

So a mock is only as good as its fidelity to the real API. If the mock returns a field the real API doesn't, or accepts a filter the real API rejects, every service test passes and production fails. That is the gap contract tests close.

Contract tests

A contract test checks the agreement between consumer and provider rather than either side's full behavior. For Contoso's portal, the contract is the subset of the S/4HANA API it relies on: entity sets, properties, keys, filters and the error behavior it handles. Two checks keep that contract honest:

Specification check: compare the consumer's expectations (fields, types, operations) with the provider's published specification, such as the OData metadata of the API version in the target system. Run it whenever either side changes.
Provider verification: run a small set of requests against the real API in a quality system and assert the response shape and key semantics the consumer depends on.

Mocks speed up service tests, and contract checks against both the specification and the real API keep those mocks honest.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

Approach	Finds	Misses
Service tests with mocks	Logic errors in the app, fast	Any difference between mock and real API
Contract tests	Breaking changes in fields, types, operations and errors	Business process problems across systems
End-to-end tests	Real flow including authentication, network and data	Little, but slow, brittle and expensive to run often

Each layer covers what the others miss.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

Released APIs are designed to be stable, so contract tests on them rarely fail, which is the point: when one does, it tells you early and precisely. They matter most where the consumer depends on details beyond the stability promise (an undocumented default sort order, a field that happens to be filled) or where your own team owns the provider, such as a custom OData service built on a RAP business object.

What would you do?

All service tests of the warranty portal pass with mocked S/4HANA. In the first end-to-end test in CMQ, claim lookups fail because the real API returns the serial number in a different property than the mock. What should change in the test strategy?

Hands-on lab · ACCELQ

Write a provider check against a public OData API

A contract test checks that the provider still returns what the consumer relies on. In ACCELQ, API logic fits a Library Action (non-UI, usable anywhere in a flow), and Insert REST call sends a request and lets you click response values to create assertions. TripPin isn't SAP, but it speaks OData V4, the same protocol as S/4HANA's released APIs. ACCELQ's docs don't mention OData by name, so treat it as REST with JSON.

Practice on TripPin People service (public OData V4 reference service, no login)

If you haven't set up ACCELQ yet, do the setup lab first. Click + > Action, choose Library Action (non UI), name it "TripPin people contract" and click Save & Continue.
Write the contract first. Your imagined consumer is a portal that looks people up, and it relies on the value array and each record's UserName, FirstName and LastName.
In the Logic Editor, click + API > Insert REST call. Set Reference Name "Get people" and Method GET. Open the TripPin link in a browser: it redirects to a private session address containing (S(...)). ACCELQ's docs don't say whether REST calls follow redirects, so use that redirected address plus ?$top=2 as a literal Endpoint URL. Click NEXT.
Leave the payload empty, since this is a GET, and click SEND REQUEST. Review the Status, Headers and Response tabs.
Create assertions by clicking values: the 200 on the Status tab, and the contract fields on the Response tab (ACCELQ generates the JSONPath). Assert only what your contract lists. Then click SAVE.
Click + > Scenario, name it "TripPin contract check", add your Library Action as its step, and run it on your Local Agent.
Simulate a provider change: edit the call's Endpoint URL to add &$select=UserName, so the API stops returning first and last names. Rerun and confirm the failure points at the missing fields. Then remove the change.

Done when The Scenario passes against the real TripPin service and fails, naming the field, when the response no longer matches the contract. Keep both Test Reports: the pass and the deliberate failure.

Learn more in ACCELQ’s docs: REST API Test Automation in ACCELQ · Verifying API Responses in ACCELQ · Library Action

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Key points

Side-by-side extensions move risk to the boundary: API contract, authentication, network and mapping.
CAP's cds.test runs service tests over HTTP with mock users and in-memory data.
Mocks generated from imported API definitions speed development but must stay faithful to the real API.
Contract tests check the consumer's expectations against the provider's specification and real responses.

Service tests in CAP

Mocking S/4HANA, carefully

Contract tests

Lesson check