You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

Salesforce生产环境触发器代码覆盖率0%,求测试类创建指导

Hey there! I get it—moving a trigger from Sandbox to Production and seeing 0% code coverage can feel overwhelming when you're new to Salesforce. Let's break this down step by step, from writing your first test class to deploying it and hitting that 75% coverage requirement.

First: Understand Your Trigger's Logic

Before writing a test class, you need to know exactly what your trigger does. Ask yourself:

  • Which object does it act on? (e.g., Account, Lead, Opportunity)
  • What events trigger it? (e.g., after insert, before update, delete)
  • What business logic does it execute? (e.g., updating a field, creating a related record, validating data)

For example, if your trigger updates an Account's Description field to "Created via trigger" right after insertion, your test class will need to simulate inserting an Account and verify that field gets updated.

Second: Write a Basic Apex Test Class

Test classes follow strict rules in Salesforce, but they're straightforward once you get the hang of it. Here's a template paired with a sample trigger to make it concrete.

Sample Trigger (for reference)

Let's say this is the trigger you deployed to Production:

trigger AccountTrigger on Account (after insert) {
    for(Account acc : Trigger.New) {
        acc.Description = 'Account created via trigger';
    }
    update Trigger.New;
}

Corresponding Test Class

@isTest
private class AccountTriggerTest {
    @isTest
    static void testAfterInsertLogic() {
        // 1. Create test data (never use real Production data!)
        Account testAccount = new Account(
            Name = 'Test Account 123', // Required field for Account
            Industry = 'Technology'
        );

        // 2. Wrap the trigger-triggering action in Test.startTest()/Test.stopTest()
        // These reset Salesforce's governor limits and ensure async logic runs
        Test.startTest();
        insert testAccount; // This fires the after insert trigger
        Test.stopTest();

        // 3. Verify the trigger did what it was supposed to do
        Account insertedAccount = [SELECT Id, Description FROM Account WHERE Id = :testAccount.Id];
        System.assertEquals(
            'Account created via trigger', 
            insertedAccount.Description, 
            'Trigger should update the Description field'
        );
    }
}

Key Parts Explained:

  • @isTest: Marks the class/method as a test (Salesforce ignores this code in production runtime)
  • Test.startTest()/Test.stopTest(): Critical for managing resource limits and ensuring any asynchronous code (like future methods) executes
  • System.assertEquals: Validates your trigger's logic works as expected—this isn't just for coverage, it ensures your code doesn't break later
Third: Deploy & Run the Test Class in Production

You should never write code directly in Production. Follow this workflow:

  1. Build and test in Sandbox first

    • Go to Setup → Search "Apex Classes" → Click "New"
    • Paste your test class code, save it
    • Run the test: Click "Run Test" on the class page, or go to Setup → "Apex Test Execution" → Select your test class and run it. Check that coverage for your trigger jumps up, and all test methods pass.
  2. Deploy the test class to Production

    • Use a Change Set (simplest for beginners):
      1. In Sandbox: Go to Setup → "Outbound Change Sets" → Create a new change set
      2. Add your test class to the change set, then upload it to Production
      3. In Production: Go to Setup → "Inbound Change Sets" → Find your uploaded change set, validate it first, then deploy it
    • Or use Salesforce CLI (if you're comfortable with command line):
      sfdx force:source:deploy -p force-app/main/default/classes/AccountTriggerTest.cls -u YourProductionOrgAlias
      
  3. Verify coverage in Production

    • Go to Setup → "Apex Test Execution" → Select your test class and run it
    • After completion, check the code coverage report—your trigger should now meet the 75% minimum requirement
Fourth: Boost Coverage for Complex Triggers

If your trigger has conditional logic (e.g., if/else statements) or multiple trigger events, you need to cover every branch:

Example: Trigger with Conditional Logic

trigger AccountTrigger on Account (after insert) {
    for(Account acc : Trigger.New) {
        if(acc.Industry == 'Technology') {
            acc.Description = 'Tech-focused Account';
        } else {
            acc.Description = 'General Business Account';
        }
    }
    update Trigger.New;
}

Test Class to Cover All Branches

@isTest
private class AccountTriggerTest {
    @isTest
    static void testTechAccount() {
        Account testAcc = new Account(Name = 'Test Tech', Industry = 'Technology');
        Test.startTest();
        insert testAcc;
        Test.stopTest();
        Account result = [SELECT Description FROM Account WHERE Id = :testAcc.Id];
        System.assertEquals('Tech-focused Account', result.Description);
    }

    @isTest
    static void testNonTechAccount() {
        Account testAcc = new Account(Name = 'Test Retail', Industry = 'Retail');
        Test.startTest();
        insert testAcc;
        Test.stopTest();
        Account result = [SELECT Description FROM Account WHERE Id = :testAcc.Id];
        System.assertEquals('General Business Account', result.Description);
    }
}
Fifth: Troubleshooting Common Issues
  • Test failures due to missing fields: Make sure all required fields on your test record are populated (e.g., Name for Account)
  • Low coverage: Check the coverage detail page for your trigger—look for unhighlighted lines (those aren't being tested) and add test scenarios to cover them
  • Governor limit errors: Use Test.startTest()/Test.stopTest() to reset limits, and avoid creating unnecessary test records

内容的提问来源于stack exchange,提问作者Ezzy

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.20 09:17:57