Read UCP business outcomes alongside HTTP status
Read the UCP response body before marking an operation successful. An HTTP 200 can carry a capability-incompatibility result, so transport status alone can misclassify the test.
Read the incompatibility example all the way through
The UCP overview includes a capability-incompatibility example with HTTP 200. The body identifies an error state and a capabilities_incompatible message. A reporter that marks every 200 response green would therefore misclassify the outcome shown in the protocol's own example.
The important lesson is specific: inspect the relevant UCP state and message under the applicable transport binding. It is not a rule that HTTP status never matters. Authentication, rate limits and other protocol failures still need to be handled according to their documented status and error information.
| Observation | Safe interpretation for a test report |
|---|---|
| HTTP response received | Transport delivered a response |
| Body recognised under the expected contract | The reporter can interpret the relevant fields |
| Capability incompatibility reported | Negotiation did not produce the required compatible capability set |
| Buyer action requested | A further step is required under the applicable flow |
| Expected business result confirmed | The specific assertion can pass |
Write an assertion that fails for the right reason
Suppose a synthetic negotiation test expects a compatible capability. Its assertion should examine that outcome, not merely the presence of a response or a non-empty object. Feed it the documented incompatibility case and verify that the report fails the intended assertion.
Then give the reporter an unreadable or unexpected body. This should not become the same outcome as a valid business rejection. One case says the operation was rejected under a recognised contract; the other says the client could not interpret what it received.
This separation saves diagnostic time. A protocol interpretation problem belongs with the integration code or reference version. A recognised business outcome may require a different next step. One generic red indicator hides the distinction and makes the operator investigate from the beginning.
Keep retries attached to their original operation
If a test performs another attempt, record the relationship between attempts and the final observed state. Do not count each successful HTTP response as a separate completed purchase or silently discard an earlier uncertain result.
Where the result is unknown, the recovery path should establish what happened before repeating a consequential action. The exact lookup and retry behaviour depends on the contract and implementation. The report should expose that behaviour instead of implying that a retry is always safe.
At the end of a run, separate passed assertions, failed assertions and cases not executed. A dependency that prevented execution reduces coverage. It does not demonstrate that the participant would reject the operation. Keeping those counts distinct makes a short test report more credible than a single success percentage with an unclear denominator.
Assert the result that matters
For a negotiation test, assert the relevant capability outcome. For a checkout transition, assert the expected state and any required next step. Do not replace these checks with a generic condition such as “response is not an error status”.
For a checkout lifecycle test, attach each assertion to the transition being exercised and the next step it permits.
If the body cannot be interpreted, report that failure directly. An unrecognised response is not evidence that the business operation succeeded.
Retain enough evidence to diagnose
Store the test case, applicable contract reference, relevant response fields and timestamp. Redact credentials and personal data.
The report should show expected and observed values side by side. This makes a mismatch actionable and avoids a dashboard where every defect appears only as “integration failed”.
When an external dependency is unavailable, distinguish an unexecuted case from a negative result. A skipped operation tells you about test coverage, not about the protocol's behaviour.
Report failures and unexecuted cases separately
A passing test establishes the asserted result under the recorded conditions. It does not certify every capability, participant or future version.
End the report with the expected, executed and unresolved case counts. Keep the relevant body fields beside each outcome so another reviewer can check how the classification was made.
