Salesforce 測試類的實踐

在Sales force開發中完善測試類是開發者必經的一個環節，代碼的部署需要保證至少75%的覆蓋率，那么該如何寫好測試類呢。

測試類定義格式如下：

@isTest
private class MyTestClass {
    @isTest static void myTest() {
        // code_block
    }     
    static testMethod void testName() {
    // code_block
    }
}

測試類允許聲明為private或者public，一般來說，單元測試的測試類都聲明為private，如果是DateFactory的話則聲明為public，其中測試類不占用計算在APEX代碼的限制中。

測試類的命名規范一般有兩種：MyClassTest 或者 TestMyClassName

兩種規范各有優劣，其中 MyClassTest緊隨Apex類之后，便於查詢與修改，TestMyClass則將所有測試類都集中在一起，便於打包。可以根據自己的習慣自行決定。

在測試類的寫法上有兩種選擇

• 用少量測試類覆蓋遠大於測試類的Apex類
• 一個測試類對應一個Apex類

從項目規范上來說，應該一個測試類對應一個Apex類，從而保證不論是后期維護，還是功能變更又或者代碼修改，都能保證代碼的質量並且在部署時更加快捷；但是少量測試類覆蓋多個Apex類同樣也是一種選擇，因為存在Apex類因為功能簡單，專門寫個測試類顯得很“多余”，而且在測試類的交叉覆蓋下，很多Apex類覆蓋率自然就上去了，項目上線迭代的速度能得到很大程度的提高。

兩種寫測試類的優缺點很明顯，少量測試類覆蓋遠大於測試類的Apex類，上線速度快，減少開發量，但是在后期維護乃至二期項目中需要花費更大的時間去處理測試類的問題，如果后來的開發者不熟悉之前的邏輯那需要的時間將更加漫長；一個測試類對應一個Apex類的寫法在項目進行中的時候會占據不少的時間，但是好處就是代碼結構清晰，后期維護的開發者不管熟不熟悉都將能游刃有余的處理之前的內容。

從長遠的角度來說，我更推薦使用后一種，作為程序員，應該花60%的時間去思考邏輯以及最優的實現方式，然后花20%的時間去實現，最后花費20%的時間進行包括業務場景在內的測試。

寫好的測試類能盡可能的驗證你寫的代碼邏輯的正確性，提升你的代碼質量，即使修改了之前的邏輯，執行你的測試方法也能知道有沒有影響你之前的邏輯，方便進行回歸測試。

說了這么多，來看一個示例吧。

/*********
    * 
    *  @Author:ricardo
    *  @Time:2018-05-09
    *  @Function 華氏溫度溫度轉換攝氏溫度
    */
public class TemperatureConverter {
    // Takes a Fahrenheit temperature and returns the Celsius equivalent.
    public static Decimal FahrenheitToCelsius(Decimal fh) {
        Decimal cs = (fh - 32) * 5/9;
        return cs.setScale(2);
    }
}

測試類如下

@isTest
private class TestTemperatureConverter {
    //正常輸入
    @isTest static void testWarmTemp() {
        Decimal celsius = TemperatureConverter.FahrenheitToCelsius(70);
        System.assertEquals(21.11,celsius);
    }
    //臨界值
    @isTest static void testFreezingPoint() {
        Decimal celsius = TemperatureConverter.FahrenheitToCelsius(32);
        System.assertEquals(0,celsius);
    }
    //異常值
    @isTest static void testBoilingPoint() {
        Decimal celsius = TemperatureConverter.FahrenheitToCelsius(212);        
        System.assertEquals(100,celsius,'這溫度超限啊');
    } 
    //反向測試
    @isTest static void testNegativeTemp() {
        Decimal celsius = TemperatureConverter.FahrenheitToCelsius(-10);
        System.assertEquals(-23.33,celsius);
    }
      
}

可以看到，測試類其實至少應該測試正常的業務流程，同時還包括異常/臨界/反向三種情況。

默認情況下，Sales force不運行測試類訪問正式的ORG數據，除了某些極端情況，比如你要測試報表相關的Apex類，可以使用@isTest(SeeAllData=true)的注解來訪問org中的數據，不過一般我們是不建議這樣操作的。那么針對這樣的情況，也就是需要重復創建一些測試數據的我們怎么做呢，答案是使用Test Utility Classes創建測試數據，也就是創建一個DateFactory類專門提供測試數據，從而避免重復創建數據的問題，也能幫助快速修復一些因為數據不全引起的測試代碼報錯的問題。

下面看一個Account的trigger示例

/***********
    *
    *  測試類最佳實踐-示例二
    *
    */
trigger AccountDeletion on Account (before delete) {
    // 如果關聯業務機會則禁止刪除Account
    for (Account a : [SELECT Id FROM Account
                     WHERE Id IN (SELECT AccountId FROM Opportunity) AND
                     Id IN :Trigger.old]) {
        Trigger.oldMap.get(a.Id).addError(
            'Cannot delete account with related opportunities.');
    }
}

准備DataFactory

@isTest
public class TestDataFactory {
    public static List<Account> createAccountsWithOpps(Integer numAccts, Integer numOppsPerAcct) {
        List<Account> accts = new List<Account>();        
        for(Integer i=0;i<numAccts;i++) {//numAccts:創建的Account數量
            Account a = new Account(Name='TestAccount' + i);
            accts.add(a);
        }
        insert accts;
        
        List<Opportunity> opps = new List<Opportunity>();
        for (Integer j=0;j<numAccts;j++) {
            Account acct = accts[j];
            //  遍歷每一個Account，都關聯創建一個對應的業務機會
            for (Integer k=0;k<numOppsPerAcct;k++) {
                opps.add(new Opportunity(Name=acct.Name + ' Opportunity ' + k,
                                       StageName='Prospecting',
                                       CloseDate=System.today().addMonths(1),
                                       AccountId=acct.Id));
            }
        }
        //  插入關聯了Accout的業務機會
        insert opps;        
        return accts;
    }
}

創建測試類

@isTest
private class TestAccountDeletion {
    @isTest static void TestDeleteAccountWithOneOpportunity() {
        // 測試類初始准備測試數據
        // 創建一個關聯業務機會的Account，並准備刪除掉
        //Account acct = new Account(Name='Test Account');
        //insert acct;
        //
        // 測試類初始准備測試數據使用DataFactory
        // 創建一個Account，關聯一個業務機會
        Account[] accts = TestDataFactory.createAccountsWithOpps(1,1);
                
        // 測試開始
        Test.startTest();
        Database.DeleteResult result = Database.delete(accts[0], false);
        Test.stopTest();
        // 校驗 
        // 應該被禁止刪除（關聯了業務機會）
        // 返回的應該是禁止刪除的錯誤提示
        System.assert(!result.isSuccess());
        System.assert(result.getErrors().size() > 0);
        System.assertEquals('不能刪除關聯業務機會的Account',
                             result.getErrors()[0].getMessage());
    }
    
     @isTest static void TestDeleteAccountWithNoOpportunities() {
        // 測試初始化
        // 創建一個Account，不關聯業務機會的
        Account[] accts = TestDataFactory.createAccountsWithOpps(1,0);
        
        // 測試開始
        Test.startTest();
        Database.DeleteResult result = Database.delete(accts[0], false);
        Test.stopTest();
        // 順利刪除
        System.assert(result.isSuccess());
    }
    
    @isTest static void TestDeleteBulkAccountsWithOneOpportunity() {
        // 初始化測試數據
        // 創建200個Account，創建一個業務機會
        Account[] accts = TestDataFactory.createAccountsWithOpps(200,1);
        
        // 測試開始
        Test.startTest();
        Database.DeleteResult[] results = Database.delete(accts, false);
        Test.stopTest();
        // 校驗結果
        // 批量刪除下，有Account是不能被刪除的，數據需要回滾
        // 所以我們會得到一個錯誤的返回值
        for(Database.DeleteResult dr : results) {
            System.assert(!dr.isSuccess());
            System.assert(dr.getErrors().size() > 0);
            System.assertEquals('不能刪除關聯業務機會的Account',
                                 dr.getErrors()[0].getMessage());
        }
    }
    
    @isTest static void TestDeleteBulkAccountsWithNoOpportunities() {
        // 初始化
        // 創建批量不關聯業務機會的數據
        Account[] accts = TestDataFactory.createAccountsWithOpps(200,0);
        
        // 測試開始
        Test.startTest();
        Database.DeleteResult[] results = Database.delete(accts, false);
        Test.stopTest();
        // 順利批量刪除
        for(Database.DeleteResult dr : results) {
            System.assert(dr.isSuccess());
        }
    }
    
}

可以看到，我們在完善自己的測試類時，不應該僅僅關注代碼的覆蓋率，同時也應該注意到對各種正常，異常，臨界諸多可能的測試，好的測試能保證代碼的質量，尤其需要注意的是經常會被忽略的批量數據處理的問題，在寫測試類的時候一般追求覆蓋率寫出來的測試方法都是模擬用戶在界面上的單記錄操作，很少會考慮批量數據的測試情況，而在實際的系統使用中是很可能遇到而且容易引起問題的地方。

測試類不應該是Salesforce強制要求的內容，而應該是屬於我們寫的代碼中不可或缺的一部分，希望能重新讓你認識到測試類的重要性

如果文中有錯誤歡迎指正，有問題歡迎留言。