Overview
Testing, Debugging, and Deployment covers four objectives: writing and running tests for triggers, controllers, classes and flows with various sources of test data; choosing among developer tools such as Salesforce DX, the Salesforce CLI and the Developer Console; debugging system issues and monitoring flows, performance and asynchronous and batch jobs; and the environments, requirements and process for deploying code and configuration.
The section exists because Salesforce will not let Apex reach production without passing tests and sufficient code coverage, and because problems in a multi-tenant, limit-bound platform are diagnosed through logs and job monitoring rather than a local debugger attached to a server. It closes the loop on the exam: the triggers and limits from Process Automation and Logic and the controllers from User Interface are what you test, debug and deploy here.
How it's tested
Questions mix code reading with process scenarios. You may see a test method and be asked why an assertion fails or which line creates the test data correctly, or read a team's situation and choose the sandbox type, tool or deployment method. Watch for the precise requirement: realistic data volume, related orgs, source tracking, or production coverage rules.
-
Fix the test
A test method fails or proves nothing, and you add Test.startTest and Test.stopTest, System.runAs, a mock, setup data or a real assertion.
-
Choose the tool or environment
A team's need is described, such as source-driven development, quick anonymous Apex or a full data copy, and you choose the CLI, Developer Console, scratch org or sandbox type.
-
Diagnose and deploy
Something fails in a flow, batch job or deployment, and you choose where to look (debug logs, Apex Jobs, failed flow interviews) or what the deployment requires.
A team needs to test performance against a copy of production with all its records and attachments before a major release. A Developer or Developer Pro sandbox copies metadata only, and a Partial Copy sandbox holds a sample defined by a template. Only a Full sandbox copies all production data, so it is the answer, even though its 29-day refresh interval makes it the least flexible choice.
Objectives 4
Official objectives from the Salesforce outline, in outline order.
4.1 Write and execute tests for triggers, controllers, classes, and flows using various sources of test data.Apex test classes, coverage rules, test data options and flow tests.
- What it means
- Apex tests are methods in @isTest classes that create data, call the code under test and assert the outcome. Production deployment requires all tests to pass, at least 75% Apex code coverage across the org, and some coverage for every trigger. Test data can come from records created in the test, a @testSetup method, a test data factory class, Test.loadData from a static resource CSV, or, rarely, SeeAllData=true. Record-triggered flows can be tested with flow tests in Flow Builder and by Apex tests that perform the triggering DML.
- What to understand
- Tests see no org data by default (setup objects such as User and Profile are an exception), and their data is rolled back afterwards. Test.startTest and Test.stopTest give the code under test a fresh set of governor limits and run queued asynchronous work synchronously at stopTest. Use System.runAs to test record sharing for a specific user, Test.setMock for callouts, and Assert or System.assertEquals so coverage actually proves behavior.
- How it shows up
- A test queries existing Accounts and finds none, an asynchronous result is not there when asserted, or a callout fails in a test, and you choose the fix.
- Common confusion
- Candidates treat 75% coverage as proof of quality; coverage only measures executed lines, and tests without assertions pass while verifying nothing.
4.2 Given a scenario, know how and when to use the Salesforce Developer tools such as Salesforce DX, Salesforce CLI, and Developer Console.Source-driven development, the CLI, scratch orgs and the Developer Console.
- What it means
- Salesforce DX is the source-driven development model: a project in version control (described by sfdx-project.json), scratch orgs created from a Dev Hub with a definition file, and the Salesforce CLI (sf commands) to create orgs, deploy and retrieve source, and run tests. The Developer Console is a browser-based tool for anonymous Apex, debug logs, SOQL queries, test runs and checkpoints. Code Builder and VS Code with the Salesforce extensions are the full IDE options.
- What to understand
- Use the CLI and DX for team development, automation and continuous integration; use the Developer Console for quick investigation such as running anonymous Apex, reading a log or checking a query plan. Scratch orgs are temporary, configurable orgs that expire, and they need a Dev Hub enabled in a production or Developer Edition org.
- How it shows up
- A scenario describes a team that wants version-controlled source, disposable environments and scripted deployments, or a developer who needs to run a quick snippet, and you choose the tool.
- Common confusion
- Candidates confuse scratch orgs with sandboxes; scratch orgs are created empty from source and a definition file, while sandboxes are copies of production metadata and possibly data.
4.3 Describe how to approach debugging system issues and monitoring flows, performance, asynchronous, and batch jobs.Debug logs, trace flags, flow debugging and monitoring async work.
- What it means
- Debug logs record database operations, Apex execution, flows and limit usage for a transaction; trace flags with debug levels decide whose activity is logged and in how much detail. Flows are debugged in Flow Builder's debug mode and monitored through fault paths, flow error emails and the paused and failed flow interviews list. Asynchronous and batch jobs are monitored on the Apex Jobs page, by querying AsyncApexJob, and through the Apex Flex Queue and Scheduled Jobs pages.
- What to understand
- Know where each problem is visible: a limit or exception in a debug log's cumulative limit usage, a failing record-triggered flow in a failed interview or error email, and a batch job's progress and error count in AsyncApexJob. For performance, read CPU and query counts in the log and use the Query Plan tool to check selectivity.
- How it shows up
- A batch job processed some records and failed others, or a flow fails for one user only, and you choose the first place to look.
- Common confusion
- Candidates expect System.debug output when no trace flag is set for the user who ran the code; no trace flag means no log.
4.4 Describe the environments, requirements, and process for deploying code and associated configurations.Sandbox types, deployment tools, test levels and production requirements.
- What it means
- Environments include Developer Edition orgs, scratch orgs and four sandbox types: Developer and Developer Pro (metadata only, refresh daily), Partial Copy (metadata plus a sample of data from a template, refresh every 5 days) and Full (complete copy of production, refresh every 29 days). Deployment tools include change sets, the Metadata API through the Salesforce CLI, unlocked packages and DevOps Center.
- What to understand
- Apex cannot be written directly in production; it is deployed with tests. Change sets require a deployment connection between related orgs and cannot delete components. Test levels control which tests run: RunLocalTests is the default for production deployments containing Apex, and RunSpecifiedTests requires each class and trigger in the package to reach 75% coverage from the specified tests. A validated deployment can be quick-deployed later without rerunning tests.
- How it shows up
- A team needs to move changes from a sandbox to production, or test with realistic data volumes, and you choose the sandbox type, tool or test level.
- Common confusion
- Candidates propose a change set between two unrelated orgs, such as two separate Developer Edition orgs; change sets only work between orgs affiliated with the same production org.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
75% code coverage
Production deployments require at least 75% of Apex lines covered by passing tests across the org, all tests passing, and every trigger having some coverage.
- Remember
- Coverage counts executed lines; it does not check whether tests assert the right outcomes.
- Tested as
- Deployment and test-quality questions.
- Trap
- Assuming each class needs 75% in every deployment, when that per-component rule applies to RunSpecifiedTests.
-
Test.startTest() and Test.stopTest()
Marks the part of a test that exercises the code under test, giving it a fresh set of governor limits.
- Remember
- Asynchronous work such as future, queueable and batch jobs started inside the block runs synchronously when stopTest is called, so assertions after it can see the results.
- Tested as
- The fix whenever an asynchronous result is missing in a test.
- Trap
- Asserting asynchronous results before stopTest or without the block at all.
-
SeeAllData
An @isTest parameter that lets a test see existing org data, which is false by default.
- Remember
- Tests should create their own data; SeeAllData=true makes tests depend on org contents and fail in other orgs.
- Tested as
- Distractor answer when a test cannot find records.
- Trap
- Turning it on instead of creating test data or using @testSetup.
-
@testSetup
A method in a test class that creates records once, which every test method in the class then sees in a fresh, rolled-back copy.
- Remember
- It reduces repeated setup code and runtime when many test methods need the same baseline data.
- Tested as
- Questions about efficient test data creation.
- Trap
- Expecting changes made in one test method to be visible in another.
-
Test.loadData and test data factories
Test.loadData inserts records from a CSV static resource; a test data factory is a reusable @isTest utility class that builds records in code.
- Remember
- Both keep test data under your control instead of relying on org data.
- Tested as
- Options in 'which sources of test data' questions.
- Trap
- Forgetting that the static resource must be uploaded and referenced by name.
-
System.runAs
Runs a block of test code as a specified user so record sharing for that user applies.
- Remember
- It enforces record sharing but not the user's object or field permissions, and it can only be used in test methods.
- Tested as
- Testing sharing behavior of controllers and triggers.
- Trap
- Expecting runAs to make a test fail on field-level security.
-
Test.setMock and HttpCalloutMock
Tests cannot make real callouts, so Test.setMock registers a class implementing HttpCalloutMock that returns a fake response.
- Remember
- Without a mock, a test that reaches a callout fails.
- Tested as
- Questions on testing integrations.
- Trap
- Trying to wrap the real callout in try/catch inside the test.
-
Debug logs and trace flags
Logs record execution details for a transaction; a trace flag on a user, Apex class or Automated Process entity with a debug level controls what is captured.
- Remember
- Raise the Apex Code or Database category to FINEST only when needed, because verbose logs grow quickly and can be truncated.
- Tested as
- Diagnosis questions about where to see an error or limit usage.
- Trap
- Looking for logs for a user who has no active trace flag.
-
AsyncApexJob and Apex Jobs page
Queued, future, batch and scheduled Apex jobs appear on the Apex Jobs page and as AsyncApexJob records with status, items processed and number of errors.
- Remember
- Database.executeBatch and System.enqueueJob return job IDs that let you query the job's progress.
- Tested as
- Monitoring questions for asynchronous and batch work.
- Trap
- Expecting a batch job's errors to stop the whole job; each execute batch is its own transaction.
-
Scratch org
A temporary, source-driven org created from a Dev Hub using a scratch org definition file, typically for one feature or test run.
- Remember
- Scratch orgs expire (up to 30 days) and start empty, so data and metadata come from your project.
- Tested as
- Tool-choice questions about Salesforce DX workflows.
- Trap
- Choosing a scratch org when a scenario needs a copy of production data.
-
Sandbox types
Developer and Developer Pro copy metadata only; Partial Copy adds a template-defined sample of data; Full copies all production data and metadata.
- Remember
- Refresh intervals are 1 day for Developer and Developer Pro, 5 days for Partial Copy and 29 days for Full.
- Tested as
- Environment-choice questions keyed on data needs and refresh frequency.
- Trap
- Picking Partial Copy for full-volume performance or load testing.
-
Change sets
Point-and-click deployment of metadata between orgs connected to the same production org through a deployment connection.
- Remember
- The target org must allow inbound changes; change sets cannot delete or rename components.
- Tested as
- Deployment-method questions.
- Trap
- Using a change set between unrelated orgs or to remove obsolete components.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Developer vs. Developer Pro vs. Partial Copy vs. Full sandbox
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Developer | Metadata copy with small storage for development | No production data; refresh every day | Using it for testing that needs real data |
| Developer Pro | Metadata copy with more storage | Larger data and file storage than Developer; still no production data | Assuming it copies records |
| Partial Copy | Metadata plus a data sample defined by a template | Representative data for QA and training; refresh every 5 days | Using it for full-volume performance testing |
| Full | Complete copy of production metadata and data | Only option for full-volume, production-like testing; refresh every 29 days | Planning frequent refreshes |
Scratch org vs. sandbox
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Scratch org | Temporary org created from source and a definition file | Starts empty, expires, built for source-driven DX work | Expecting production data in it |
| Sandbox | Copy of production created from Setup | Holds production metadata, and data for Partial Copy and Full | Treating it as disposable per feature |
Salesforce CLI vs. Developer Console
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Salesforce CLI | Command-line interface for Salesforce DX | Scripted org creation, deploys, retrieves and test runs for teams and CI | Using it as a log viewer for a quick look |
| Developer Console | Browser-based tool inside the org | Anonymous Apex, debug logs, SOQL query plan and quick test runs | Using it as a team deployment pipeline |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Turn on SeeAllData
- What candidates pick
- Add SeeAllData=true because the test cannot find any Accounts.
- Why it looks right
- It makes the query return records immediately.
- Why it's wrong
- Tests should not depend on org data; they become fragile and fail where that data does not exist. Create data in the test or in @testSetup.
Clue to watch for The test queries records it never created.
-
Assert too early
- What candidates pick
- Assert the result right after calling a method that enqueues a Queueable or calls a future method.
- Why it looks right
- The method call has returned, so its work seems complete.
- Why it's wrong
- Asynchronous work runs later unless the call is wrapped in Test.startTest and Test.stopTest, which forces it to complete at stopTest.
Clue to watch for The code under test starts asynchronous Apex.
-
runAs for permissions
- What candidates pick
- Use System.runAs with a restricted user to prove a controller hides a field.
- Why it looks right
- runAs switches the running user, so it seems to apply all of that user's restrictions.
- Why it's wrong
- runAs enforces record sharing only; object and field permissions are not enforced unless the code itself uses user mode or permission checks.
Clue to watch for The requirement is about field or object access, not which records are visible.
-
Partial for performance
- What candidates pick
- A Partial Copy sandbox for load and performance testing.
- Why it looks right
- It contains real data and refreshes more often than Full.
- Why it's wrong
- Partial Copy holds only a template-defined sample; realistic volume testing needs a Full sandbox.
Clue to watch for Phrases like 'all production data', 'full volume' or 'performance testing'.
-
Change set anywhere
- What candidates pick
- A change set to move metadata from a partner's Developer Edition org to the company's production org.
- Why it looks right
- Change sets are the simplest deployment tool.
- Why it's wrong
- Change sets work only between orgs affiliated with the same production org through a deployment connection; unrelated orgs need the Metadata API, CLI or a package.
Clue to watch for The source and target orgs belong to different companies or are unrelated orgs.
-
Coverage equals quality
- What candidates pick
- Accept a test class that reaches 90% coverage with no assertions.
- Why it looks right
- It satisfies the deployment rule easily.
- Why it's wrong
- Coverage counts lines executed, not behavior verified; without assertions, wrong results still pass.
Clue to watch for The question asks for the best test or what proves the code works.
-
Debug without a trace flag
- What candidates pick
- Add System.debug statements and expect output after a user reports an error.
- Why it looks right
- Debug statements are the usual way to print diagnostics.
- Why it's wrong
- Logs are generated only when a trace flag is active for that user, class or process at the time it runs.
Clue to watch for The issue occurs for a specific user and no logging was set up.
Answer framework
For any testing, debugging or deployment scenario, apply these steps in order.
- Identify the stage: writing tests, choosing a tool, diagnosing a failure or deploying a change.
- For tests, create your own data, wrap the code under test in Test.startTest and Test.stopTest, use runAs or mocks where the scenario needs them, and assert real outcomes.
- For tools, choose the CLI and scratch orgs for source-driven team work and the Developer Console for quick investigation.
- For failures, go to the right evidence: debug logs with trace flags, failed flow interviews, or AsyncApexJob for batch and queued jobs.
- For deployment, match the environment to the data the scenario needs and confirm production rules: passing tests, 75% coverage and the right deployment tool.
Practice question
Want more like this? The Salesforce PD1 practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with Apex testing, the most heavily scenario-tested objective here. Write tests for a trigger you built earlier: create data in @testSetup, test 200 records to prove bulkification, add Test.startTest and Test.stopTest around asynchronous code, use System.runAs for a sharing check, and mock one callout. Write real assertions every time; coverage without assertions is the habit the exam punishes.
Next, learn the environments as a table: sandbox types with their data and refresh intervals, scratch orgs, and Developer Edition orgs. Pair that with deployment tools, change set rules, and test levels for production. These are memorization-heavy and commonly underestimated by developers who never run releases themselves.
Then practice tooling hands-on. Create a scratch org with the Salesforce CLI, deploy and retrieve source, and run tests from the command line. In the Developer Console, run anonymous Apex, set a trace flag, and read the cumulative limit usage in a log. Start a batch job and watch it in Apex Jobs.
Afterwards, take full mixed practice exams, since this section's questions often reuse trigger and component code from the other sections.
FAQ
How much of the Platform Developer I exam is Testing, Debugging, and Deployment?
It is 20% of the exam, the smallest of the four sections. Applied to 60 scored questions that suggests about 12 questions as a planning estimate; Salesforce does not publish per-section counts.
What code coverage is required to deploy Apex to production?
All tests must pass, Apex code coverage across the org must be at least 75%, and every trigger must have some coverage. When you deploy with RunSpecifiedTests, each class and trigger in the deployment must reach 75% from the specified tests.
Why does my test not see existing records?
Apex tests do not see org data by default, apart from setup objects such as User and Profile. Create the data in the test, a @testSetup method, a data factory or Test.loadData rather than switching on SeeAllData.
What do Test.startTest() and Test.stopTest() do?
They mark the code under test, give it a fresh set of governor limits, and force asynchronous work started inside the block to finish when stopTest runs, so you can assert its results.
Which sandbox should I use for performance testing?
A Full sandbox, because it is the only type that copies all production data. Partial Copy holds only a sample, and Developer and Developer Pro sandboxes contain metadata only.
When should I use the Developer Console instead of the CLI?
Use the Developer Console for quick, in-org work such as running anonymous Apex, reading debug logs or checking a query plan. Use the Salesforce CLI with Salesforce DX for version-controlled, repeatable team development and deployments.
How do I monitor a batch job that partly failed?
Check the Apex Jobs page or query AsyncApexJob for its status, items processed and number of errors, and use debug logs or your own error logging in execute to find which records failed. Each execute call is a separate transaction, so other batches can still succeed.
Other CRM & Business Applications certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 4 knowledge
You have covered Apex and flow testing, test data sources, developer tools, debug logs and job monitoring, and sandbox and deployment rules. Check whether you can fix failing tests and pick the right environment under exam timing.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the Salesforce PD1 AI tutor Get any concept explained your way