Module 14 Cheat Sheet

EXTERNAL TEST
=============

client
 ↓
deployed Mule
 ↓
real Salesforce
 ↓
verify target state


VERIFY TWO THINGS
=================

API response

AND

Salesforce result


USE SALESFORCE API / SOQL
=========================

prefer direct backend verification
over Salesforce UI


TEST DATA
=========

unique per test

except when intentionally
testing idempotency


ASYNC
=====

202
↓
poll condition
↓
bounded timeout

never fixed sleep


IDEMPOTENCY
===========

send same request repeatedly
and concurrently

verify:
count = 1
same Salesforce ID
correct final state


NEGATIVE TESTS
==============

bad input
→ proper error

AND

no Salesforce side effect


CONTRACT
========

OpenAPI schema validation
+
business assertions


MUNIT
=====

fast/internal/mocked


EXTERNAL
========

real deployment/config/auth/schema/
permissions/downstream state

The interview sentence to memorize is:

“For deployed integration tests I don't stop at HTTP assertions—I verify the resulting Salesforce state through API/SOQL. For asynchronous flows I poll the business completion condition rather than sleep, and for idempotency I repeat the same request concurrently and prove there is exactly one downstream business entity.”

The next module is Module 15: Deployment and Operations — Maven project structure, build/deploy lifecycle, CloudHub 2.0, Runtime Manager, environment promotion, CI/CD, runtime properties, logs, health checks, rollback, and what you need to know when someone asks, “Okay, you wrote the Mule flow—how does it actually get into production?”