The full adapt, boost, restore, clean lifecycle, with safe rollback.

LATdx ships several commands that mutate Apex source or org state. They map to two distinct workflows (“rapid execution” and “test acceleration”) plus the cleanup path. This page ties them together.

Two Adaptation Modes

LATdx supports two ways to run tests faster. They share the same transformation engine but differ in what gets deployed and how the tests execute.

Rapid execution accepts one of -f, -d, -n, or -t to select files, directories, class names, or tests.

Rapid execution wraps test bodies in anonymous Apex and runs them through the SOAP API. Nothing persists in the org. Test acceleration transforms the entire codebase, deploys the adapted classes alongside the LATdx managed package, and lets the standard Salesforce test runner pick them up. The transformation in both cases reroutes SOQL/DML/System.* calls through LATdx proxies that simulate the database in-memory.

If you only need fast local feedback, you never have to leave latdx test run. The rest of this page covers test acceleration and the lifecycle of the artifacts it creates.

Commands at a Glance

latdx adapt

Currently a placeholder. The command accepts -f/--file <path> (required) and an optional -o/--output <path>, reads the file, and either writes the contents back unchanged or prints them. It exists as the entry point for upcoming single-file transformation modes (rapid execution, deploy-dbsim, deploy-passthrough); use latdx boost for the working directory-level flow today.

latdx boost

latdx boost -d ./force-app/main/default/classes -o ./build/adapted

Boost walks the source directory recursively, transforms every .cls file, and writes the adapted versions to the output directory.

The transformation:

• Reroutes Database.*, System.*, and SOQL/DML statements through LATdx managed-package proxies. The proxies activate inside Test.isRunningTest() and run against the in-memory simulator.
• Preserves @isTest, @TestSetup, @TestVisible, class modifiers, and visibility, the standard test runner has to execute the adapted classes unchanged.
• Injects LATDX_ORIG markers that record the pre-transform body, so latdx restore can reverse the change deterministically.

The summary line reports transformed / unchanged / errors. Per-file errors are logged at warn level; the overall command still succeeds with a non-zero error count, so check the summary in CI.

The output directory is a transient artifact. Do not commit it to source control; deploy it to the org and discard it after restore (or after merging the branch).

Typical Test-Acceleration Loop

latdx boost -d force-app/main/default/classes -o build/adapted

sf project deploy start -d build/adapted -o my-org

sf apex test run -o my-org -w 10

latdx restore -o my-org

latdx restore

Reverses what boost deployed, either in a local directory or in a Salesforce org.

latdx restore -d ./build/adapted              # restore on disk
latdx restore -o my-org                       # restore deployed classes in the org
latdx restore -o my-org --dry-run             # list what would change without changing it
latdx restore -o my-org --json                # structured result

In dir mode, restore reads the LATDX_ORIG markers in adapted files and writes back the original method bodies in place. In org mode, it queries the org for adapted classes, materializes the originals from markers, and redeployes them via the Tooling API.

If any class fails to restore, the command exits with code 1 and reports the offenders. Use --dry-run to preview before touching the org.

latdx clean

Removes LATdx-deployed helper classes from an org. This is distinct from restore: restore reverses adapted user classes, while clean removes the infrastructure LATdx put there (mocks, trigger handlers, generated initializers).

latdx clean -o my-org
latdx clean -o my-org --dry-run
latdx clean -o my-org --json

The query targets classes named latdx* with a null NamespacePrefix, excluding sidecar latdx_<Name>_ORIG classes that restore may still need. The output lists deleted classes and triggers.

You usually do not need to run clean directly; latdx uninstall calls it for you. Reach for it standalone if you accidentally deployed adapted classes and want to wipe the helpers without touching the rest of the org.

latdx uninstall

The full-removal entry point. It runs in this order:

1. restore, revert adapted user classes to their originals.
2. clean, delete LATdx helper classes.
3. Managed-package uninstall, remove the latdx-sf managed package.

latdx uninstall -o my-org
latdx uninstall -o my-org --dry-run
latdx uninstall -o my-org --json

--dry-run prints what each step would do without performing it. --json returns a structured envelope with per-step results, including the package’s blockers array if removal is blocked by external references.

Exit codes:

• 0, all three steps succeeded.
• 1, restoration failed, package uninstall blocked, or an internal error occurred.

The CLI does not retry. Re-run latdx uninstall --dry-run to see what’s left if a step failed midway.

When to Run Which

What Survives Across Runs

Safety Notes

• Run --dry-run on production-shaped orgs before invoking the real command. The CLI does not require an explicit --prod-ok flag; target the right org alias intentionally.
• latdx uninstall is the only command that removes the managed package; restore and clean leave the package in place so re-installation is not required.
• All five commands respect the auto-grant FLS/OLS opt-out (LATDX_SKIP_TEST_RUNNER_ACCESS); see Authentication & Org Targeting.

See also