MSAMM
Back to course

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

Testing idempotency explicitly

Lesson 149 of 175 · 2 min

Run it TWICE and assert on the TARGET. The one test that would catch the most expensive class of defect in this course. Module 9 argued that duplicates are inevitable and Module 10 said the same from the events side. This is the test, and it takes five minutes. THE PROCEDURE IS ALL OF IT. Process a record. Count what is in the target. Process the identical input again. Count again. The two counts must be equal. "ASSERT ON THE TARGET" IS THE PART THAT DOES THE WORK, and the reason the test is usually done wrong. The tempting assertion is that the second run was skipped — that the instance shows "already processed". That passes against an implementation which skips for the wrong reason, and it also FAILS against a correct implementation that processes and overwrites with an identical result, which is a perfectly legitimate design. The property anybody

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
Testing idempotency explicitly — Oracle Integration Cloud: Building Integrations That Survive Production — MSAMM