Testing Policy

Org-wide testing policies, coverage requirements, and guiding principles for Apex and LWC testing

Category: Salesforce
Tags: testing standards salesforce apex lwc test-coverage policy

Author: Joe Callin Name: Joe Callin Title: Sr. Salesforce Developer Email: joe@jcallin.dev

Introduction

Purpose

This document establishes org-wide testing policies and guiding principles for both Apex and Lightning Web Component (LWC) testing within your Salesforce project or codebase. These policies ensure consistent, maintainable, and high-quality test coverage across all code.

Scope

These policies apply to all test classes, test methods, and test utilities in the project. All tests must comply with these standards and pass Salesforce Code Analyzer validation using the project's ruleset.

Test Coverage Requirements

Coverage Goals

Target: 100% code coverage for all production code.

Minimum: 90% code coverage required. Any code below 90% coverage must have documented reasoning explaining why full coverage is not feasible or necessary.

Coverage Reporting

  • Coverage must be verified before code is committed
  • Use Salesforce CLI to generate coverage reports: sf apex run test --code-coverage
  • Coverage reports should be reviewed as part of code review process
  • Coverage gaps must be addressed or documented

Exclusions and Exceptions

Code that may be excluded from coverage requirements (with documentation):

  • Getter/Setter methods - Simple property accessors may be excluded if they don't contain business logic
  • Exception constructors - Custom exception classes with only constructors
  • Test utilities - Test factory and utility classes themselves (meta-testing)
  • Deprecated code - Code marked for removal (must have removal plan)

Documentation Format:

/**
 * @description Simple getter method for account name
 * @coverage-excluded - Simple property accessor with no business logic
 */
public String getAccountName() {
    return this.accountName;
}

Coverage Validation

  • All test classes must be run before committing code
  • Coverage must meet minimum requirements before PR approval
  • CI/CD pipelines should validate coverage automatically
  • Coverage reports should be included in PR reviews

1:1 Test Method to Code Method Relationship

Requirement

Each public and protected method in production code should have a corresponding test method.

This ensures comprehensive test coverage and makes it easy to identify which tests cover which methods.

Implementation

  • One test method per production method
  • Test method names should clearly indicate which method they test
  • Test methods should focus on testing a single method's behavior

Example:

// Production code
public class ACME_AccountService {
    public static Account createAccount(String accountName) {
        // Implementation
    }

    public static List<Account> getAccountsByType(String type) {
        // Implementation
    }
}

// Test code
@isTest
private static class ACME_AccountServiceTest {
    @isTest
    private static void test_createAccount() {
        // Tests createAccount method - primary test covering main path
    }

    @isTest
    private static void test_getAccountsByType() {
        // Tests getAccountsByType method - primary test covering main path
    }
}

Exceptions

Exceptions to the 1:1 rule are acceptable in these cases:

  1. Private methods - May be tested indirectly through public methods, or use @TestVisible if direct testing is necessary
  2. Overloaded methods - Each overload should have its own test method
  3. Complex methods - Methods with multiple distinct behaviors may have multiple test methods (one per behavior)
  4. Helper methods - Utility methods may be tested as part of calling method tests if they're simple

Example of multiple tests for complex method:

// Production code
public static ACME_Response processRecords(List<SObject> records) {
    // Complex method with multiple behaviors
}

// Test code - Multiple tests for different behaviors
@isTest
private static void test_processRecords() {
    // Primary test - tests successful processing (main path)
}

@isTest
private static void test_processRecords_emptyList() {
    // Additional test - tests empty list handling
}

@isTest
private static void test_processRecords_invalidRecords() {
    // Additional test - tests error handling
}

@TestVisible Usage

Only use @TestVisible on private methods for 1:1 testing standard.

This allows test classes to access private methods when necessary to achieve 1:1 test method to code method relationship.

Example:

public class ACME_AccountSelector {
    @TestVisible
    private String buildFieldList(Set<String> fields) {
        // Private method accessible to tests
    }
}

@isTest
private static class ACME_AccountSelectorTest {
    @isTest
    private static void test_buildFieldList() {
        // Primary test - can directly test private method
    }
}

Platform-Specific Testing Standards

Detailed testing patterns, data management strategies, mocking approaches, and test organization guidelines are covered in the platform-specific testing pages:

  • Apex Testing Standards - Comprehensive Apex testing patterns including test data management, assertion best practices, mocking strategies, test organization, and Code Analyzer compliance for tests
  • LWC Testing Standards - Jest testing framework setup, component testing patterns, wire adapter mocking, event testing, and accessibility testing

Change History

Version 2.1 - 2026-03-26

  • Clarified org-wide testing policy language and relationship to platform-specific standards.
  • Refined structure and examples in the policy hub while preserving the split-topic approach from 2.0.

Version 2.0 - 2026-03-25

  • Restructured: split into org-wide policy hub with platform-specific subpages

Version 1.0 - 2026-01-14

  • Initial release of testing standards documentation

Last Updated: 2026-03-26 Version: 2.1