MSAMM
Back to course

Oracle Integration Cloud: Building Integrations That Survive Production · Module 15 · Testing an integration properly

Testing without the other system

Lesson 146 of 175 · 3 min · Free preview

The partner is not ready and go-live is not moving. Stubs, mock endpoints and recorded payloads — and WHAT EACH OF THEM CANNOT TELL YOU. This situation is normal rather than exceptional. The bank's test environment appears in week nine of a ten-week project; the partner's API is documented and not yet built. You build against something you invented, and the whole risk is forgetting that is what you did. A RECORDED PAYLOAD IS THE STRONGEST OPTION AND IS USUALLY AVAILABLE. A real response captured from the real system once, replayed. It is real data in a real shape, so it tells you the mapping handles what that system actually sends — and it tells you nothing about any other response, including every error. A MOCK ENDPOINT ANSWERS THE SHAPE YOU WROTE INTO IT. It exercises the call, the parsing and the mapping, and it is entirely a description of

This lesson is free

Watch the full lesson, with its written notes, without an account. It is one of the free lessons this course opens with.

Watch the full lesson

Get the free lessons by email

We will email you a link to every free lesson in this course. No account needed, and one message only.

In this module: Module 15 · Testing an integration properly

  1. 1What "tested" means for an integration
  2. 2Testing without the other systemFree preview
  3. 3Choosing test data that would fail
  4. 4Testing the failure paths
  5. 5Testing idempotency explicitly
  6. 6End-to-end with the business
  7. 7What breaks: the UAT that proved nothing
  8. 8Lab briefing · A test plan somebody would sign