Mapping and contract tests

Mapping defects are the most common integration defects, and the cheapest to find before partners are involved. Contract defects, where the two sides simply disagree about the message, are the most expensive to find late, because each side's tests pass on its own. This lesson covers both.

Mapping tests

A mapping test feeds a known input message into one mapping and compares the output with an expected message, field by field. It needs no partner, no connected system and often no deployed flow. The test set is a library of input and expected-output pairs, derived from the mapping specification and real (scrambled) samples, stored in version control with the integration content.

• Every mapped field at least once, compared at the target, not just "the message arrived".
• Multi-item messages with different values per item, to catch context errors that repeat or drop item values.
• Boundaries: longest allowed field lengths, decimals and rounding, dates at month end and year end, time zones.
• Value mappings: every entry, plus one value that is not in the table.
• Optional and empty fields: absent, empty and whitespace, which mappings often treat differently.
• Character sets: accented names such as those Contoso will meet in Monterrey, and special characters in free text.

How you run them depends on the technology. Message mappings and scripts in Cloud Integration can be exercised with sample payloads in a test tenant with receivers stubbed; depending on your tenant, the flow editor may also let you simulate parts of a flow with a sample payload. Groovy scripts can be unit tested outside the tenant like any other code. On the S/4HANA side, ABAP logic in exits or AIF actions can be covered with ABAP Unit, SAP's unit test framework, which Kenji's team already uses.

Contract tests

A contract is the agreement between a producer and a consumer about a message: structure, data types, mandatory fields, allowed values, and for APIs the operations and responses. In SAP landscapes, contracts take several forms: an IDoc basic type with extensions, an XML schema (XSD) for a partner format, an OpenAPI description for an HTTP API. A contract test checks one side against the agreed contract without needing the other side: does the producer's output validate against it, and does the consumer accept every valid variant?

The most valuable habit is versioning the contract and the shared samples and running the contract tests whenever either side changes. When Lakeside upgrades its order intake and adds a mandatory field, a contract test against their new schema fails in Contoso's pipeline the day the new schema is shared, not on cutover weekend.