Apex Testing Framework and Requirements

Apex Testing Framework & Requirements – Complete Guide for Salesforce Platform Developer 1

Why Is the Apex Testing Framework Important?

The Apex Testing Framework is one of the most critical topics on the Salesforce Platform Developer 1 exam. Salesforce enforces a strong testing culture because Apex code runs in a multi-tenant environment. Without proper testing, a single piece of poorly written code could affect all organizations sharing the same infrastructure. Testing ensures code quality, prevents regressions, and is mandatory before deploying Apex to a production environment.

From an exam perspective, you can expect multiple questions on testing requirements, best practices, annotations, and how the framework behaves at runtime. Mastering this topic is essential to passing the exam.

What Is the Apex Testing Framework?

The Apex Testing Framework is a built-in set of tools provided by Salesforce that allows developers to write and execute unit tests for their Apex code. It is modeled loosely on testing frameworks like JUnit. Key components include:

• Test Classes and Methods: Classes annotated with @isTest that contain methods also annotated with @isTest (or the legacy keyword testMethod).
• System.assert Methods: Used to verify expected outcomes — System.assertEquals(), System.assertNotEquals(), and System.assert().
• Test.startTest() / Test.stopTest(): Methods that reset governor limits within a test context, allowing you to isolate the code being tested from the test setup.
• Test Data Factory pattern: A reusable utility class for creating test data.
• @TestSetup: An annotation for a method that creates common test records once, which are then rolled back and available for every test method in the class.

Key Requirements You Must Know

1. Code Coverage Minimums:
- Salesforce requires a minimum of 75% overall Apex code coverage to deploy to production.
- Every trigger must have at least 1% coverage (meaning at least some test must invoke it).
- System.assert statements are not required for coverage, but they are a best practice and are heavily recommended.

2. Test Data Isolation:
- By default, test methods cannot see or access existing org data. They operate in an isolated context.
- To access org data, you must use the annotation @isTest(SeeAllData=true). However, this is considered a bad practice and should be avoided whenever possible because it makes tests dependent on existing data, which can be unreliable.
- Some standard objects like User, Profile, RecordType, and Organization are always accessible in tests without SeeAllData=true.

3. Test Classes Do Not Count Against Code Limits:
- Code inside @isTest classes does not count toward the org's Apex code size limit.
- Test classes also do not count toward code coverage calculations (you don't need to test your test code).

4. Governor Limits in Tests:
- Each test method gets its own set of governor limits.
- Using Test.startTest() and Test.stopTest() provides a fresh set of governor limits between those calls, allowing you to isolate the code under test from the data setup portion.
- Test.stopTest() also forces all asynchronous operations (future methods, queueable, batch) to execute synchronously so you can assert their results.

How the Testing Framework Works – Step by Step

1. Create a test class: Annotate the class with @isTest.
2. Optionally use @TestSetup: Define a method annotated with @TestSetup to create records that all test methods in the class can share. These records are rolled back after each test method, ensuring isolation between methods.
3. Write test methods: Each method is annotated with @isTest. Inside, you typically follow the Arrange-Act-Assert pattern:
- Arrange: Create test data or query records from @TestSetup.
- Act: Call the method or trigger the operation you want to test, typically between Test.startTest() and Test.stopTest().
- Assert: Use System.assertEquals(), System.assertNotEquals(), or System.assert() to verify the outcome.
4. Run tests: Tests can be run from the Developer Console, VS Code (Salesforce Extensions), Setup UI, or via the Tooling API/Metadata API.
5. Review results: Check code coverage percentages and ensure all assertions pass.

Important Annotations and Keywords

• @isTest — Marks a class or method as a test. The class is not counted against the Apex code size limit.
• @isTest(SeeAllData=true) — Allows the test to access all org data. Use sparingly.
• @TestSetup — A method-level annotation for creating shared test data. Only one @TestSetup method per test class is allowed.
• @isTest(isParallel=true) — Allows the test to run in parallel even if parallel testing is disabled at the org level.
• Test.startTest() / Test.stopTest() — Resets governor limits and forces async code to complete.
• Test.isRunningTest() — Returns true if the code is executing in a test context. Useful for bypassing certain logic (e.g., callouts) during testing, though overuse is discouraged.

Best Practices for Apex Testing

• Always create your own test data. Do not rely on org data.
• Use a Test Data Factory — a public utility class annotated with @isTest that has methods for creating standard test records. This promotes reusability.
• Test positive scenarios (expected behavior), negative scenarios (error handling, validation rules), bulk scenarios (200+ records to test trigger bulkification), and user/permission scenarios (System.runAs()).
• Always include System.assert statements. Code coverage alone does not prove your code works correctly.
• Use System.runAs() to test code running as different users, which also resets governor limits for certain sharing-related scenarios.
• Avoid hardcoded IDs in test data.
• Test bulk operations: Salesforce triggers can fire on up to 200 records at a time, so test with at least 200 records to ensure your code handles bulk scenarios.

Common Pitfalls

• Forgetting that @TestSetup data is rolled back after each test method, so each method gets a clean copy.
• Assuming that mixed DML operations (e.g., inserting a User and an Account in the same transaction) will work the same in tests — they won't. Use System.runAs() to work around this.
• Not calling Test.stopTest(), which means asynchronous code won't complete before assertions run.
• Using SeeAllData=true unnecessarily, making tests fragile and environment-dependent.
• Thinking that 75% coverage on every single class is required — the requirement is 75% overall, but every trigger needs some coverage.

Exam Tips: Answering Questions on Apex Testing Framework and Requirements

1. Memorize the 75% rule: The minimum overall code coverage for deployment to production is 75%. Individual classes can have less, but every trigger must have at least some coverage. This is one of the most commonly tested facts.

2. Know the default data isolation: By default, tests do NOT see org data. If a question asks how to access existing records in a test, the answer involves @isTest(SeeAllData=true). But if the question asks for a best practice, the answer is to create your own data.

3. Understand Test.startTest() and Test.stopTest(): Expect questions about when governor limits reset and how asynchronous code behaves. Remember that Test.stopTest() forces async execution to complete synchronously.

4. Know @TestSetup behavior: Data created in @TestSetup is available to all test methods but is rolled back between methods. Only one @TestSetup method per class is allowed. If a question describes a scenario where test data needs to be shared efficiently, @TestSetup is typically the correct answer.

5. System.runAs() is key for user context testing: It lets you execute code as a specific user, useful for testing sharing rules, profile-based permissions, and working around mixed DML issues.

6. Read questions carefully for the word 'best practice' vs. 'possible': Using SeeAllData=true is possible, but never a best practice. Creating your own test data is the best practice.

7. Bulk testing: If a question mentions trigger testing or handling governor limits, think about testing with 200+ records.

8. Assertions matter: While not technically required for code coverage, Salesforce and the exam emphasize that tests without assertions are incomplete. If a question asks what makes a test meaningful or robust, assert statements are the answer.

9. Test classes don't count against code limits: If a question asks about Apex code storage limits, remember that @isTest annotated classes are excluded.

10. Deployment and testing: During deployment, all local tests (or specified tests) run in the target org. If overall coverage drops below 75% or any test fails, the deployment is rejected. Know the difference between Run Local Tests, Run All Tests, and Run Specified Tests deployment options.

By thoroughly understanding these concepts and practicing with scenario-based questions, you will be well-prepared to handle any Apex Testing Framework question on the Platform Developer 1 exam.