Adaptation Lifecycle: Adapt, Boost, Restore, Clean, Uninstall

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.

| Mode | Entry point | Deploys to org? | Package required? | Best for | | --------------------- | ------------------------------------- | --------------- | ----------------- | ---------------------------------------------------- | --------------- | -------------- | ---------------------------------------------------- | | Rapid execution | latdx test run [-f | -d | -n | -t] | No (or minimal) | No (file mode) | Inner-loop dev: edit → run → see results in seconds. | | Test acceleration | latdx boost then sf apex test run | Yes | Yes | CI / orgs that must execute via the standard runner. |

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

Command	What it does	Mutates source?	Mutates org?
`latdx adapt`	Single-file transformation entry point (placeholder today; no-op).	No (yet)	No
`latdx boost`	Transforms every `.cls` in a source dir into deployable adapted classes.	New output dir	No (deploy is your step)
`latdx restore`	Reverses boost adaptations (in a directory or in an org).	Yes	Yes (org mode)
`latdx clean`	Removes deployed LATdx helper classes (`latdx_*`) from an org.	No	Yes
`latdx uninstall`	Full removal: `restore` then `clean` then managed-package uninstall.	No	Yes (deeply)

`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


# 1. transform the code (per branch or per CI run)
latdx boost -d force-app/main/default/classes -o build/adapted
 
# 2. deploy adapted classes (LATdx managed package must already be installed)
sf project deploy start -d build/adapted -o my-org
 
# 3. run the tests through the standard runner
sf apex test run -o my-org -w 10
 
# 4. (optional) tear down the adaptation when you're done
latdx restore -o my-org

The managed package install is a one-time step per org; see Authentication & Org Targeting for the package readiness check.

`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:

restore — revert adapted user classes to their originals.
clean — delete LATdx helper classes.
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

Situation	Command(s)
Local dev: edit a test, run it, get fast feedback.	`latdx test run -f path/to/Test.cls`
CI: run the whole test suite via the standard runner with simulator-backed speedups.	`latdx boost -d ... -o ...` → deploy → `sf apex test run` → `latdx restore -o my-org`
Branch is dead, want to remove its adapted classes from a long-lived sandbox.	`latdx restore -o my-org`
Cleaning helper classes left behind after a misconfigured run.	`latdx clean -o my-org`
Removing LATdx entirely from an org (e.g., decommissioning).	`latdx uninstall -o my-org`

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.