MSAMM
Back to course

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

Testing the failure paths

Lesson 148 of 175 · 3 min

A fault handler that has NEVER FIRED is untested code on the path you will need most. Provoking each deliberately. Module 8 was spent building fault handling, and almost none of it is exercised by a normal test. The handlers sit there, plausible and unrun — and the first time they execute is during a real incident, at the worst possible moment, when nobody has capacity to discover that the handler itself is broken. AND HANDLERS ARE BROKEN MORE OFTEN THAN ORDINARY CODE, for a specific reason: they are written by imagining a failure rather than by observing one. The developer pictures the timeout and writes what should happen. That picture is frequently wrong about what the platform actually delivers — which exception, in which shape, at which scope. SO PROVOKE EACH ONE, AND ALL OF THEM ARE PROVOKABLE. Point a connection at an unreachable host for a connectivity failure.

The full lesson is part of the course

The video, the complete written lesson and the module quiz are included in Oracle Integration Cloud: Building Integrations That Survive Production, with a certificate on completion and a fourteen-day refund window.

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