精通开发者沙盒：Salesforce 开发人员高效开发的核心指南

背景与应用场景

作为一名 Salesforce 开发人员，开发者沙盒 (Developer Sandbox) 是我们日常工作中不可或缺的工具。它提供了一个与生产环境完全隔离但功能高度相似的开发和测试环境，确保我们在不影响实际业务运作的前提下，安全地进行代码编写、功能测试和实验。理解并高效利用开发者沙盒，是实现高质量、高效率 Salesforce 开发的关键。

Salesforce 提供了多种沙盒类型，以满足不同的开发和测试需求：

全复制沙盒 (Full Copy Sandbox)：包含所有元数据 (Metadata) 和生产环境数据，但刷新频率较低，通常用于 UAT (用户验收测试) 或性能测试。
部分复制沙盒 (Partial Copy Sandbox)：包含所有元数据和指定数量的生产数据，刷新频率比全复制沙盒高，适用于集成测试。
开发者沙盒 (Developer Sandbox)：仅复制生产环境的元数据，不包含任何生产数据。它拥有相对较小的数据存储空间（通常为 200 MB），但刷新频率最高（每天一次），是开发人员进行日常开发、单元测试和故障排查的首选。
开发者专业沙盒 (Developer Pro Sandbox)：与开发者沙盒类似，但数据存储空间更大（通常为 1 GB），适用于需要更多测试数据的开发任务。

本文将重点探讨开发者沙盒，因为它是我们开发人员最常接触和使用的环境。其主要应用场景包括：

新功能开发 (New Feature Development)：在不影响生产系统稳定性的前提下，安全地构建和实现新的业务功能。
Bug 修复 (Bug Fixing)：复现和修复生产环境中的错误，并验证修复方案。
单元测试编写与执行 (Unit Test Creation and Execution)：编写并运行 Apex 单元测试，确保代码逻辑的正确性，并达到必要的代码覆盖率 (Code Coverage)。
集成测试 (Integration Testing)：验证多个组件或外部系统之间的交互是否按预期工作。
培训与学习 (Training and Learning)：为新团队成员提供一个安全的学习环境，或实验新的 Salesforce 功能和技术。
版本控制与部署前的验证 (Version Control and Pre-deployment Validation)：在将代码提交到版本控制系统 (Version Control System) 并部署到生产环境之前，进行全面的功能和性能验证。

开发者沙盒的隔离性、灵活性和易用性，使其成为 Salesforce 开发生命周期中不可或缺的一环。

原理说明

开发者沙盒的核心原理在于隔离与复制。当您创建一个开发者沙盒时，Salesforce 会从您的生产组织 (Production Org) 复制一份元数据 (Metadata) 的快照。这份快照包含了您生产组织中的所有配置，例如自定义对象、字段、Apex 类、Visualforce 页面、Lightning 组件、工作流规则、流程自动化等等。然而，它不会复制任何实际的业务数据。

开发者沙盒特性

仅包含元数据 (Metadata Only)：这是开发者沙盒与全复制或部分复制沙盒最显著的区别。这意味着您的沙盒一开始是“空白”的，没有客户记录、销售机会或任何其他业务数据。开发人员需要自己创建测试数据，或通过脚本导入少量数据进行测试。
数据存储限制 (Data Storage Limits)：通常为 200 MB。这个限制对于元数据开发和单元测试是足够的，但对于需要大量数据的集成测试或性能测试可能不足。
文件存储限制 (File Storage Limits)：通常为 200 MB。
刷新频率 (Refresh Frequency)：开发者沙盒可以每天刷新一次。刷新操作会将沙盒的元数据重新同步到其源生产组织的最新状态。请注意，刷新会删除沙盒中的所有数据和任何在沙盒中独立进行的元数据更改，因此在刷新前务必确保您的更改已备份或部署。
用途 (Purpose)：专为开发人员提供独立的编码、构建和单元测试环境。由于不含生产数据，可以降低数据泄露的风险，并提高开发速度。

与生产环境的关系

开发者沙盒与生产环境 (Production Environment) 之间存在一种清晰的单向关系：

独立性 (Independence)：沙盒是一个完全独立的 Salesforce 实例。您在沙盒中所做的任何配置更改、代码修改或数据操作，都不会自动影响生产环境。这种隔离性是其最重要的优点，它允许开发人员自由地实验、犯错和学习，而无需担心对实际业务造成中断。
部署流程 (Deployment Process)：当您在沙盒中完成开发和测试后，需要将这些更改部署到生产环境。常用的部署工具有：
- 变更集 (Change Sets)：Salesforce 提供的原生部署工具，适用于从沙盒到相关生产环境的部署。
- Salesforce DX (Salesforce DX)：现代化的开发工具集，支持源代码驱动的开发、团队协作和 CI/CD (持续集成/持续部署)。通过 SFDX，您可以将沙盒作为暂存环境 (Scratch Org) 或传统沙盒 (Sandbox Org) 来管理元数据。
- 元数据 API (Metadata API)：通过编程方式（如 Ant 迁移工具或其他第三方工具）进行元数据部署。

环境初始化与测试数据

由于开发者沙盒不包含生产数据，因此在进行测试时，我们通常需要自己创建测试数据。这可以通过以下几种方式实现：

Apex 测试类中创建 (Creation in Apex Test Classes)：在 Apex 单元测试中，使用 DML (数据操作语言) 语句（如 `insert`、`update`）动态创建测试数据是最佳实践。这些数据仅在测试执行期间存在，并在测试完成后回滚。
Apex 脚本或匿名执行窗口 (Apex Scripts or Anonymous Execution Window)：对于手动测试或需要少量数据进行功能测试的场景，可以通过开发者控制台 (Developer Console) 的匿名执行窗口运行 Apex 脚本来创建数据。
数据加载工具 (Data Loading Tools)：例如 Salesforce Data Loader 或其他 ETL (提取、转换、加载) 工具，可以用于从外部文件加载少量测试数据。但这通常更适用于需要大量数据或特定数据模式的场景。

作为开发人员，熟练掌握在 Apex 中创建和管理测试数据是至关重要的，因为这直接关系到单元测试的有效性和代码覆盖率的达标。

示例代码

作为 Salesforce 开发人员，我们在开发者沙盒中最常执行的任务之一就是编写和运行 Apex 单元测试。以下示例代码展示了如何编写一个简单的 Apex 类和其对应的测试类。该测试类负责创建测试数据、调用被测试的方法，并断言 (Assert) 结果的正确性。

被测试的 Apex 类：AccountManager

这是一个简单的 Apex 类，用于创建指定数量的客户 (Account) 记录。

public class AccountManager {
    /**
     * @description 创建指定数量的客户记录
     * @param numAccounts 要创建的客户数量
     * @return 创建的客户列表
     */
    public static List<Account> createAccounts(Integer numAccounts) {
        // 创建一个列表来存放新的客户记录
        List<Account> accounts = new List<Account>();
        // 循环创建指定数量的客户
        for (Integer i = 0; i < numAccounts; i++) {
            // 实例化一个新客户对象，并设置其名称和电话
            Account acc = new Account(Name = 'Test Account ' + i, Phone = '123-456-7890');
            accounts.add(acc); // 将客户添加到列表中
        }
        // 如果有客户需要插入，则执行 DML 操作
        if (!accounts.isEmpty()) {
            insert accounts;
        }
        return accounts; // 返回创建的客户列表
    }
}

对应的 Apex 测试类：AccountManager_Test

这个测试类包含了两个测试方法，用于验证 AccountManager.createAccounts 方法的功能。在开发者沙盒中，您会频繁编写这类测试来确保您的代码质量。

@isTest
private class AccountManager_Test {
    /**
     * @description 测试 createAccounts 方法是否能成功创建指定数量的客户
     */
    @isTest static void testCreateAccountsPositive() {
        // Step 1: 准备测试数据
        // 对于这个特定的方法，createAccounts 内部会创建数据，所以这里无需额外创建。
        // 如果被测试方法依赖现有数据，则在此处使用 insert 语句创建。
        // 例如：
        // List<Opportunity> opps = new List<Opportunity>();
        // opps.add(new Opportunity(Name='Test Opp', StageName='Prospecting', CloseDate=Date.today()));
        // insert opps;

        // 使用 Test.startTest() 和 Test.stopTest() 来重置 Governor Limits
        // 并且可以测试异步 Apex 的行为
        Test.startTest();
        // Step 2: 调用被测试的方法
        List<Account> createdAccounts = AccountManager.createAccounts(5);
        Test.stopTest();

        // Step 3: 断言结果
        // 验证返回的列表大小是否符合预期
        System.assertEquals(5, createdAccounts.size(), 'Expected 5 accounts to be created.');

        // 验证每个创建的客户 Id 是否不为空（表示已成功插入数据库）
        for (Account acc : createdAccounts) {
            System.assert(acc.Id != null, 'Account Id should not be null after insert.');
            System.assert(acc.Name.startsWith('Test Account'), 'Account name should start with "Test Account".');
        }

        // 可选：通过 SOQL 查询验证数据库状态
        // 这对于 DML 操作来说是一个很好的实践，以确保数据持久化
        List<Account> queriedAccounts = [SELECT Id, Name FROM Account WHERE Name LIKE 'Test Account%'];
        System.assertEquals(5, queriedAccounts.size(), 'Expected 5 accounts in the database.');
    }

    /**
     * @description 测试 createAccounts 方法在创建零个客户时的行为
     */
    @isTest static void testCreateZeroAccounts() {
        Test.startTest();
        // 调用方法，请求创建 0 个客户
        List<Account> createdAccounts = AccountManager.createAccounts(0);
        Test.stopTest();

        // 验证返回的列表为空
        System.assertEquals(0, createdAccounts.size(), 'Expected 0 accounts to be created.');

        // 验证数据库中没有留下任何名为 'Test Account%' 的客户记录
        List<Account> queriedAccounts = [SELECT Id FROM Account WHERE Name LIKE 'Test Account%'];
        System.assertEquals(0, queriedAccounts.size(), 'Expected 0 accounts in the database.');
    }

    /**
     * @description 测试 createAccounts 方法是否能处理最大数量的 DML 操作
     *              虽然这里我们只插入少量，但可以通过修改循环次数模拟大批量操作
     */
    @isTest static void testCreateLargeNumberOfAccounts() {
        // Salesforce Governor Limits 允许在一个事务中插入最多 10000 条记录
        // 我们测试一个接近但低于此限制的数量，以验证其健壮性
        Integer maxAccountsToCreate = 200; // 实际场景中，可以测试到 10000

        Test.startTest();
        List<Account> createdAccounts = AccountManager.createAccounts(maxAccountsToCreate);
        Test.stopTest();

        System.assertEquals(maxAccountsToCreate, createdAccounts.size(), 'Expected ' + maxAccountsToCreate + ' accounts to be created.');
        List<Account> queriedAccounts = [SELECT Id FROM Account WHERE Name LIKE 'Test Account%'];
        System.assertEquals(maxAccountsToCreate, queriedAccounts.size(), 'Expected ' + maxAccountsToCreate + ' accounts in the database.');
    }
}

在开发者沙盒中，您可以通过开发者控制台 (Developer Console) 或 VS Code (Visual Studio Code) 插件来部署这些代码，并运行测试。运行测试后，您将看到代码覆盖率报告，确保您的代码满足 Salesforce 部署要求（通常是 75% 以上的代码覆盖率）。

注意事项

在使用开发者沙盒进行开发时，作为一名开发人员，需要注意以下几点以确保开发流程的顺畅和代码质量：

数据隔离与测试数据管理

开发者沙盒是元数据驱动 (Metadata-driven) 的，这意味着它不包含生产环境的任何实际业务数据。所有测试所需的数据都必须手动创建或通过 Apex 脚本、数据加载工具导入。在编写单元测试时，务必在 `@isTest` 方法中创建所有必要的测试数据。避免依赖沙盒中预先存在的数据，因为沙盒随时可能被刷新，导致数据丢失。

最佳实践： 使用 @isTest(SeeAllData=false)（默认行为）确保测试方法完全隔离，不会看到沙盒中的任何非测试数据。
数据创建： 优先在 Apex 测试方法内部通过 DML 语句创建测试数据。
数据清理： 测试方法执行后，创建的数据会自动回滚，无需手动清理。

权限管理 (Permission Management)

在沙盒中测试时，请确保您的沙盒用户拥有执行所需操作的正确简档 (Profile) 和权限集 (Permission Set)。沙盒的权限设置会从生产组织复制过来，但如果生产组织中的权限在沙盒创建后有更新，沙盒可能不会立即同步。测试不同的用户角色和权限对于确保代码在不同场景下都能正常工作至关重要。使用 System.runAs() 方法可以在单元测试中模拟不同用户的执行上下文，从而有效地测试权限。

API 限制与管控制限 (API Limits and Governor Limits)

尽管沙盒与生产环境隔离，但 Salesforce 的管控制限 (Governor Limits)（例如 SOQL 查询数量、DML 操作数量、CPU 执行时间等）在沙盒中同样适用。开发人员在编写代码时必须始终牢记这些限制，并编写高效、可扩展的代码。尽管沙盒可能不会像生产环境那样频繁地触及 API 调用限制，但了解这些限制并进行相应的测试，可以避免在部署到生产环境后出现意外问题。

测试批量操作： 在沙盒中测试 Apex 代码时，务必模拟大批量数据操作，以确保代码能够处理海量数据而不会触及管控制限。
异步 Apex： 考虑使用异步 Apex (例如 @future 方法、批处理 Apex (Batch Apex)、队列式 Apex (Queueable Apex)) 来处理需要长时间运行或消耗大量资源的逻辑。

刷新策略 (Refresh Strategy)

开发者沙盒可以每天刷新一次。刷新操作会将沙盒的元数据与源生产组织同步，但会删除沙盒中所有的数据和在沙盒中独立进行的任何元数据更改。因此，在刷新沙盒之前，务必确保您所有的代码和配置更改都已经：

已推送到您的版本控制系统（如 Git）。
已通过变更集或 Salesforce DX 部署到更高环境（如集成测试沙盒或生产环境），或者至少已备份。

缺乏有效的刷新策略可能导致开发工作丢失。

版本控制集成 (Version Control Integration)

强烈建议将开发者沙盒与版本控制系统 (Version Control System)（例如 Git）集成。沙盒是您工作的临时环境，而版本控制系统是您的代码和元数据的“真相之源”。

频繁提交： 定期将沙盒中的更改提取 (retrieve) 到本地并提交到版本控制系统。
分支策略： 使用合适的分支策略（如 Git Flow 或 GitHub Flow）来管理不同的功能开发和错误修复。

命名约定 (Naming Conventions) 与代码质量

在沙盒中开发时，请遵循统一的命名约定和代码质量标准。这包括 Apex 类、触发器、Visualforce 页面、Lightning 组件以及自定义对象和字段的命名。良好的命名约定可以提高代码的可读性和可维护性，特别是在团队协作环境中。进行代码审查 (Code Review) 是在沙盒中开发时的重要环节。

安全 (Security)

即使是开发者沙盒，也要避免使用真实的敏感生产数据进行测试。如果确实需要类似生产数据进行测试，请确保这些数据经过了匿名化 (Anonymization) 或去标识化 (De-identification) 处理，以避免泄露个人身份信息 (PII) 或其他敏感企业数据。

总结与最佳实践

开发者沙盒是 Salesforce 开发人员的基石。通过有效利用它，我们可以显著提高开发效率、代码质量和系统的稳定性。以下是一些总结和最佳实践：

充分利用沙盒的隔离性

始终在开发者沙盒中进行所有的新功能开发、Bug 修复和实验。永远不要在生产环境中直接进行开发或测试。沙盒提供了一个安全的“操场”，让您可以无所顾忌地尝试和学习。

自动化测试优先

作为开发人员，编写高质量的单元测试 (Unit Tests) 并在沙盒中持续运行它们是至关重要的。确保您的 Apex 代码具有高代码覆盖率，并且所有关键逻辑都经过了测试。自动化测试是发现问题、确保代码质量和支持未来重构的基础。

测试数据策略： 始终在测试方法内部创建所需的测试数据，避免依赖沙盒中的持久化数据。
断言的艺术： 编写清晰、具体的断言，验证业务逻辑的预期输出和系统状态。

版本控制是您的生命线

将您的 Salesforce 元数据视为代码，并将其置于严格的版本控制之下。定期从沙盒中提取 (retrieve) 元数据并提交到 Git 等版本控制系统。这不仅能保护您的开发成果，还能促进团队协作、实现代码回滚和构建 CI/CD 管道。

持续集成/持续部署 (CI/CD)

将开发者沙盒集成到您的 CI/CD 流程中。这意味着当您提交代码到版本控制系统时，自动化工具可以在开发者沙盒或集成沙盒中自动运行测试、执行静态代码分析，并最终部署到更高环境。CI/CD 能够显著缩短反馈循环，提高部署速度和可靠性。

环境同步与维护

定期刷新您的开发者沙盒，使其元数据与生产环境保持同步。这有助于确保您在最新的生产配置上进行开发，减少部署时的冲突和意外。同时，及时删除不再使用的沙盒，保持沙盒环境的整洁。

小步快跑，频繁部署

采用敏捷开发方法，将功能分解成小的、可管理的代码块。在沙盒中完成一个小功能后，尽快进行单元测试，并通过版本控制提交，并部署到集成环境。这种“小步快跑”的策略有助于及早发现问题，降低集成风险。

文档与知识共享

记录您的开发过程、技术决策和解决方案。与团队成员共享沙盒使用经验和最佳实践。良好的文档和知识共享有助于提升整个团队的效率和开发能力。

总之，开发者沙盒不仅仅是一个开发环境，它更是您作为 Salesforce 开发人员实现高效、高质量开发工作的强大基石。熟练掌握其原理、利用其特性，并遵循最佳实践，将使您在 Salesforce 开发之路上如虎添翼。

Salesforce中文网