Deployment Requirements and Test Execution

Deployment Requirements & Test Execution – Salesforce Platform Developer 1 Exam Guide

Why Deployment Requirements and Test Execution Matter

Deployment is the process of moving metadata (Apex classes, triggers, Visualforce pages, Lightning components, custom objects, etc.) from one Salesforce environment to another — typically from a sandbox to production. Understanding the deployment requirements and how test execution works is critical for any Salesforce developer because:

• Production stability: Salesforce enforces strict code-coverage and testing rules before code can reach production. This protects orgs from untested, potentially breaking changes.
• Exam relevance: The Platform Developer 1 exam frequently tests your knowledge of deployment rules, required test coverage percentages, and the behavior of test classes during deployment.
• Real-world practice: Virtually every Salesforce project involves deploying changes, so mastering these concepts is essential for day-to-day work.

What Are Deployment Requirements?

When you deploy Apex code (classes and triggers) to a production organization, Salesforce enforces several requirements:

1. 75% Overall Code Coverage: All Apex code in the production org (including the code being deployed) must have at least 75% code coverage from unit tests. This is an org-wide requirement, not per-class.

2. Every Trigger Must Have Coverage: Each individual Apex trigger must have at least some (minimum 1%) test coverage. You cannot deploy a trigger with 0% coverage, even if the overall org coverage is above 75%.

3. All Tests Must Pass: Every unit test in the org must pass during the deployment validation. If even one test fails, the entire deployment is blocked.

4. No Compilation Errors: All Apex code must compile without errors.

5. Component Dependencies: All referenced components (custom fields, objects, etc.) must exist in the target org or be included in the deployment package.

Key Nuances to Understand

• The 75% coverage requirement applies to the entire org, not to each individual class. However, best practice is to aim for 75%+ coverage on every class and trigger individually.
• Test classes themselves (annotated with @isTest) do not count toward the code coverage total — they are excluded from the denominator.
• System.debug statements, comments, and blank lines are not counted as executable lines of code.
• Code coverage is calculated based on the lines of code executed during test methods versus total executable lines.

How Test Execution Works During Deployment

When you initiate a deployment to production (via Change Sets, the Metadata API, Salesforce CLI, or tools like Workbench), the following happens:

1. Validation Phase: Salesforce first validates that all components can be deployed — checking for compilation errors, missing dependencies, etc.

2. Test Execution Phase: Salesforce runs the Apex tests. Depending on your deployment method and settings, you may choose:
• Run Local Tests (Default for Production): Runs all tests in the org except those from managed packages. This is the default behavior for production deployments.
• Run All Tests: Runs every test in the org, including tests from managed packages.
• Run Specified Tests: Runs only the tests you explicitly list. When using this option, the specified tests must still provide 75% overall coverage for the code being deployed, and every trigger in the deployment must be covered.
• No Test Run: Available for sandbox-to-sandbox deployments. Production deployments always require tests to run (unless deploying only non-code components).

3. Deployment Phase: If all tests pass and coverage requirements are met, the metadata is committed to the target org.

4. Rollback on Failure: If any test fails or coverage is insufficient, the deployment is rolled back and no changes are applied. Deployments are all-or-nothing transactions.

Test Execution Contexts and Behaviors

• @isTest annotation: All test classes must be annotated with @isTest. Methods inside must be static, return void, and also be annotated with @isTest or use the testMethod keyword (legacy).
• Test.startTest() / Test.stopTest(): These reset governor limits, providing a fresh set of limits for the code between them. Test.stopTest() also forces asynchronous operations (future methods, queueable, batch) to execute synchronously.
• @TestSetup: Methods annotated with @TestSetup run once per test class and create test data available to all test methods in that class. This improves efficiency.
• SeeAllData=true: By default, test methods do not have access to org data. Using @isTest(SeeAllData=true) grants access, but this is strongly discouraged as it makes tests fragile and environment-dependent.
• Test.isRunningTest(): Returns true when code is executing in a test context. Useful for bypassing callouts or certain logic in tests, but should be used sparingly.
• isTest(isParallel=true): Indicates a test class can run in parallel, improving deployment speed.

Deployment Tools

• Change Sets: Point-and-click deployment between connected orgs. Suitable for simple deployments but limited in flexibility.
• Salesforce CLI (sf / sfdx): Command-line tool for source-driven development and deployment. Supports CI/CD pipelines.
• Metadata API: The underlying API used by all deployment tools. Can be used directly via tools like Workbench or Ant Migration Tool.
• Packages (Managed/Unmanaged): Used for distributing apps. Managed packages have stricter requirements and IP protection.

Sandbox Types and Their Role

• Developer Sandbox: Copy of production metadata only. Limited storage. Good for individual development.
• Developer Pro Sandbox: Same as Developer but with more storage.
• Partial Copy Sandbox: Metadata + a subset of data defined by a sandbox template.
• Full Sandbox: Complete copy of production metadata and data. Used for staging, UAT, and performance testing.

Tests do not need to run when deploying to sandboxes (unless you choose to run them), but they are required for production deployments.

Common Deployment Issues

• Insufficient code coverage: The most common deployment failure. Ensure tests cover at least 75% org-wide and every trigger has coverage.
• Existing failing tests: Tests already in production that fail (e.g., due to data changes or configuration drift) will block your deployment even if they are unrelated to your changes.
• Missing dependencies: Deploying a class that references a custom field not included in the deployment package will fail.
• Order of execution issues: Some components must be deployed before others (e.g., custom objects before Apex classes that reference them).
• Hardcoded IDs: Tests that rely on specific record IDs will fail in different environments.

Best Practices for Test Execution and Deployment

• Always create your own test data — never rely on SeeAllData=true.
• Use @TestSetup to create data once per test class for efficiency.
• Use Test.startTest() and Test.stopTest() to isolate governor limits and execute asynchronous code.
• Test positive scenarios, negative scenarios (expected errors), bulk scenarios (200+ records), and user permission scenarios (System.runAs()).
• Assert outcomes using System.assertEquals(), System.assertNotEquals(), and System.assert(). Tests without assertions may provide coverage but do not truly validate behavior.
• Aim for meaningful test coverage — don't just hit 75%; test real business logic, edge cases, and error handling.
• Use @isTest on test classes to ensure they don't count against your org's Apex character limit.

Exam Tips: Answering Questions on Deployment Requirements and Test Execution

1. Remember the magic number: 75%. The minimum org-wide Apex code coverage required for production deployment is 75%. This is the single most tested fact about deployment.

2. Every trigger needs some coverage. Even if your org is at 90% overall, a trigger with 0% coverage will block deployment.

3. All tests must pass. Not just the tests related to your changes — all tests in the org (or all local tests, depending on the test level selected).

4. Test classes don't count in coverage calculations. Lines in @isTest classes are excluded from both the numerator and denominator.

5. Sandboxes don't require tests. Test execution is only mandatory for production deployments. If a question mentions deploying to a sandbox, tests are optional.

6. Know the default test level. For production deployments, the default is to run local tests (excluding managed package tests).

7. Understand Test.startTest() and Test.stopTest(). Questions often focus on governor limit resets and how asynchronous code runs synchronously after Test.stopTest().

8. SeeAllData is false by default. Tests are isolated from org data unless explicitly annotated with SeeAllData=true. Know that this is considered bad practice.

9. Deployment is all-or-nothing. If one component fails or one test fails, nothing is deployed. There is no partial deployment.

10. System.runAs() is for testing user contexts. It allows you to test record sharing, field-level security, and profile-based permissions within a test method. It does not reset governor limits (only Test.startTest() does that).

11. Watch for trick answers about code coverage percentages. If a question says "each class must have 75% coverage," that is incorrect — the requirement is org-wide. However, each trigger must have some coverage (greater than 0%).

12. Read questions carefully for the target environment. The rules differ between sandbox and production. Production deployments have strict requirements; sandbox deployments are more lenient.

13. Validate-only deployments run tests but do not actually deploy. This is useful for checking if a deployment would succeed without committing changes. Know that a validated deployment can be quick-deployed within 10 days if it passes.

14. Mock callouts in tests. Apex tests cannot make real HTTP callouts. Use HttpCalloutMock or StaticResourceCalloutMock interfaces. Questions may test whether you know that callouts fail in test context without mocks.

15. When in doubt, focus on assertions. The exam values tests that actually verify behavior. A test method that creates records but has no assert statements is considered incomplete, even if it provides line coverage.