Why a dependency graph can't pick your tests
· We measured syntactic dependency graphs against real coverage across five Salesforce projects. On one, the graph found 1 of the 46 test classes that exercise a metadata-dispatched trigger handler. What that means for impact analysis, and for any tool that offers to skip tests for you.
The Salesforce deploy queue, explained
· One deployment at a time per org, a queue you cannot see, and a Pending state that looks identical whether your job is next or lost. How the queue actually works, what "stuck" precisely means, and when cancel-and-resubmit is safe.
What a release receipt should contain
· "Tests passed" is a claim about a moment and a worktree. A receipt is evidence: a payload digest, a source revision, an org fingerprint, gate results, a validation job identity, and an expiry, each field closing a specific gap between what was proven and what ships.
Flaky Apex tests: where they come from and how to find them
· The five sources of Apex flakiness (order dependence, time assumptions, data collisions, async timing, org state), and a detection discipline built on recorded run conditions instead of gut feel.
Branch coverage for Apex: what line coverage misses
· A line with a ternary counts as covered when only one arm ever ran. Worked Apex examples of tests that cover every line and miss branches, where statement-level branch coverage itself stops, and why mutation testing is the next rung.
Reading an Apex test failure like the engine does
· The runner knew the assertion operands, the SOQL and DML that preceded the failure, and whether the same test passed before. Debugging is reconstructing context the engine already had, an argument for runners that hand it over.
How to mock HTTP callouts in Apex tests
· Test.setMock and the one-method HttpCalloutMock interface, a configurable mock for the suite, a router mock for multi-callout flows, and the uncommitted-work gotcha, plus why the failure-response matrix is the part worth testing.
Apex CPU time limit exceeded: how to find the hotspot and fix the shape
· The 10-second budget is shared by your Apex, your Flows, and managed packages, but not database time. The usual culprits (nested loops, recursion, describes in loops), Limits.getCpuTime() checkpoints, and the 200-record budget test.
Testing async Apex: Queueable, Batchable, Scheduled, and @future
· Async work runs at Test.stopTest, not when you call it. The per-flavor playbook: one batch scope of data, the Test.isRunningTest() chain guard, testing a schedulable's execute directly, and asserting on AsyncApexJob.
SeeAllData is a debt: test data factories in Apex
· Tests that read org data fail everywhere except the org they were written against. The factory pattern that absorbs schema churn in one file, @testSetup snapshots, and why fast local runs remove the incentive that creates SeeAllData.
Running Apex tests with the sf CLI: the complete workflow, and where the time goes
· Every sf apex run test flag that matters, the async queue and --wait, recovering results with sf apex get test, and an honest accounting of why the slow part is never the CLI itself.
The scratch org tax: what org setup really costs, and which parts you can stop paying
· Create, deploy, permsets, seed data, expiry, Dev Hub allocations: the full scratch org lifecycle priced honestly, and why the highest-frequency org use (running Apex tests) is the easiest to take off the org.
Debugging Apex with debug logs: the workflow, the limits, and the way out
· Trace flags, log levels, sf apex tail log, and reading a FINEST log without losing the afternoon, plus why it's print-statement debugging with extra steps, and what breakpoints in Apex look like instead.
Too many SOQL queries: 101 and the per-record query behind it
· The error is rarely about the limit. It's a query running per record, usually in a trigger under bulk load. How to find the loop, the collect-query-map fix, and the 200-record test that keeps it fixed.
Detect the Nimbus runtime from Apex
· A one-line isNimbus() helper using standard SOQL on Organization.InstanceName tells your Apex whether it is running locally or in a real org, and you can set the instance name yourself in nimbus.properties.
Design Salesforce like a distributed system
· Bounded contexts, event-driven architecture, platform events as facts not commands, and the Trigger Actions framework: the discipline network boundaries enforce for free, plus how to test every cross-domain contract locally without an org.
The hidden cost of the Apex feedback loop
· Deploy, wait, run tests, wait, switch back. The real cost of the deploy-and-wait cycle, measured in hours, focus, and the designs it quietly discourages.
75% code coverage is a deployment gate, not a test strategy
· Salesforce requires 75% Apex code coverage to deploy. That number says almost nothing about whether your code works. What coverage measures, and what to measure instead.
The Apex inner loop in VS Code: run, test, and debug without an org
· How to run Apex tests, step through a live debugger, and watch coverage in VS Code, with no scratch org, no sandbox, and no deploy step between you and a result.
What Test.startTest and Test.stopTest actually do
· Two jobs: a fresh set of governor limits for the code under test, and synchronous execution of async work at stopTest. Everything about where to arrange, act, and assert follows from those two.
Do you still need an Apex trigger framework?
· Ordering, bypass, and recursion: the three problems a trigger framework actually solves, why a ~40-line handler covers most teams, and when metadata-driven frameworks earn their weight.