Module 13 cheat sheet

MUNIT
=====

native Mule testing framework


TEST STRUCTURE
==============

Behavior
  mocks

Execution
  invoke flow

Validation
  assertions/verifications


SET EVENT
=========

create input:
payload
attributes
vars


MOCK WHEN
=========

replace processor behavior

Salesforce
HTTP
DB
etc.

can return:
payload
error


ASSERT THAT
===========

assert Mule event state


VERIFY CALL
===========

did processor execute?
how many times?


SPY
===

observe real processor
without replacing it


IMPORTANT TESTS
===============

happy path
Choice branches
validation
DataWeave mappings
error handlers
retry exhaustion
partial failures
negative side-effect checks


DO NOT MOCK EVERYTHING
======================

real Salesforce tests still needed for:

SOQL
schema
permissions
OAuth
validation rules
External ID uniqueness
real connector behavior


CI
==

MUnit + Maven
run on PR/build


COVERAGE
========

useful signal
not proof of quality

The interview sentence to memorize:

“I use MUnit to isolate Mule flow behavior by mocking external processors, asserting the resulting Mule event, and verifying meaningful downstream calls. I keep real Salesforce integration tests separately because mocks cannot prove SOQL, schema, permissions, authentication, validation rules, or true External-ID behavior.”

Next is Module 14: external automated testing of Mule integrations — this will map directly to your current skillset: API tests from Playwright/TypeScript, test-data setup through APIs, verifying Mule responses plus Salesforce state, schema validation, eventual-consistency polling, idempotency tests, negative/error tests, and deciding what belongs in MUnit versus external end-to-end automation.