作者： 夏晚

虽然Salesforce从业人员应该尽量使用标准功能来实现需求，
但仍不可避免的要用到代码。

标准功能的话，Salesforce会自己负责质量（虽然Bug频发。。。），
对于自定义功能，Salesforce则制定了质量标准，
比如，如果总体代码覆盖率不到75%，无法Deploy。

一般的Apex Code，就像那些出现在Trigger里，出现在Controller里的代码，
测试类都很好写，就按照
1. 准备测试数据
2. 执行业务逻辑
3. 断言执行结果
按套路打就行了。

除此之外，另一些apex code，需要特别的测法。
Salesforce作为CRM系统，无法避免的要与其他系统进行数据交互。
大部分情况，我们只需要把salesforce的标准集成文档和权限已经配置妥当的账号，提供给对方就好，
但是，当我们需要将业务封装起来的时候，就需要自己建WebService。
况且，Salesforce主动调用外部系统接口的时候，又要区分是Rest还是SOAP。

对于Apex Rest Callout可以使用下面三种方式（代码示例点击链接）
1. HttpCalloutMock
比较常见的写法，有极大的可拓展性（毕竟连响应结果都要自己Code进去）。
2. StaticResourceCalloutMock
与LoadData是一对好兄弟，都是在Test Class中利用StaticResource，可以很好的做到测试数据与测试代码分离。
3. MultiStaticResourceCalloutMock
StaticResourceCalloutMock的复数URL版。

对于Apex SOAP Callout，Salesforce也提供了一种方式。
1. WebServiceMock

以上是Callout的测试类写法，原理均是构造一个Mock类，然后提供一个假的response。
你总不能期待每次跑测试类的时候，让人家集成方的服务器真的去响应你吧？

那么Callin呢。
首先，处理Callin的Apex Class一定是WebService。
WebService也分为Rest Webservice和SOAP WebService。
对于Rest WebService，Salesforce并没有提供类似与Mock类的工具类，所以我们直接去构造上下文环境。
在实际情况种，上下文环境是由系统进行构造的，这里我们代替系统。

        .................
        RestRequest request = new RestRequest();
        request.requestURI = 'https://[InstanceName].salesforce.com/services/apexrest/xxxxxx/';
        request.httpMethod = 'GET';
        RestContext.request = request;
        /** Call your WebService like below **/
        MyWebService.MyFoo();
        .................

对于SOAP Webservice就简单多了。因为不需要处理上下文环境的参数等内容，直接处理方法中的参数就好，
所以就当作普通的Apex Code处理就可以，不需要特殊的操作。

除此之外。

虽然目前我还没见有人用过，但是Salesforce还是提供了一个Stub接口，用来做Mock框架。
它的好处是可以实现单元测试的完全解耦，对各个小模块进行单独的测试。
就目前市面上各个大公司的状况来看。。。能好好写个断言就不错了。（捂脸）（尴尬）

之前对于Salesforce的RollBack机制没有进行深入的思考。
那天，闲来无事，有人问了我一个问题。

问说，下面的代码在匿名快执行完之后插进去了几条数据。

ObjectA__c objA = new ObjectA__c();
objA.Name = "TestA";
insert objA;

List<ObjectB__c> objBList = new List<ObjectB__c>
for(Integer i = 0; i < 200; i++) {
    ObjectB__c objB = new ObjectB__c();
    objB.Name = "TestB" + i;
    insert ojbB;
}

我大概扫了一眼，问的是Governor Limit嘛，答案是150，送分题，不谢。
但又隐约的觉得不大对劲，既然拿来问我，肯定有坑。
立马打开Developer Console试了一下。
看到了结果倒吸了一口冷气。。。。。。。。0，一条都没插进去。全都RollBack了？

咦？不对啊，那一定是匿名块做了特殊的设置。试试Controller。
要不然我以前在Controller里写个什么劲儿的SavePoint。
VF:

<apex:page controller="TestRollbackClass">
    <apex:form>
    	<apex:commandButton action="{!save}" value="Button"/>  
    </apex:form>
</apex:page>

Apex Class:

public class TestRollbackClass {

    public void save() {     
        ObjectA__c oa = new ObjectA__c();
        oa.Name = 'TestA';
        insert oa;

	ObjectB__c ob = new ObjectB__c();
        ob.Name = 'testB';
        insert ob;
    }
}

我在ObjectB上加了一个Validation Rule,保证新建ObjectB记录的一定会报错。
这次总该如预期一般只有ObjectA被插进去了吧。

结果一跑，唉？ 还是都RollBack了？
瞬间怀疑人生。既然都自动RollBack了，那我以前为什么必须写SavePoint？
去翻了下Release Note，也没找到相关的变动。

没办法，一定是写法问题，我试着按照Coding Standard写一次

public class TestRollbackClass {

    public void save() {
	ObjectA__c oa = new ObjectA__c();
	oa.Name = 'Test2';
        insert oa;
        try {
            ObjectB__c ob = new ObjectB__c();
        	ob.Name = 'test1';
        	insert ob;
        } catch(Exception e) {
            ApexPages.addMessage(new ApexPages.Message(ApexPages.Severity.Error, e.getMessage()));
        }
    }
}

再次执行，第一条数据ObjectA居然插进去了。
我瞬间明白了点什么。

Salesforce的机制应该是这样的，
如果Transaction被异常中断，则Rollback全部的数据变动。
如果异常被捕获，则已经正常commit的数据变动会落实。出错的部分无效。

按照开发潜规则，应该展现给User更Friendly的错误信息，而不是可怕的Trace Log信息。
所以我以前的公司要求捕获所有可能的异常并替换成友好的错误信息。
这样的话，Transaction一定不会被异常中断，所以自动全部Rollback的机制从来没有启用过。
那么为了防止在出错时插入脏数据，Salesforce提供了SavePoint。
用法如下：

public class TestRollbackClass {

    public void save() {
        SavePoint sp = Database.setSavepoint();
		ObjectA__c oa = new ObjectA__c();
		oa.Name = 'Test2';
        insert oa;
        try {
            ObjectB__c ob = new ObjectB__c();
        	ob.Name = 'test1';
        	insert ob;
        } catch(Exception e) {
            Database.rollback(sp);
            ApexPages.addMessage(new ApexPages.Message(ApexPages.Severity.Error, e.getMessage()));
        }
    }
}

如果ObjectB插入出错，已insert的ObjectA也会回滚。达到目的。

做Salesforce开发，最让人头疼的事情，莫过于Debug。

不同于Java开发，已经有了一系列成熟的Debug工具，
Salesforce开发者最常用的手段只有输出log，就如同Javascript开发一样。
不过随着现代浏览器的兴起，就算是Javascript开发也可以debug了。

对于一个老手来说，添加System.debug()然后查log，虽然已经足够。
但是，面对巨型transaction的时候，就要面临Debug Log的限制。
1. log总体大小不能超过3MB，否则随机截断（不管官网怎么说，我觉得是随机的，囧）
2. log只能存留七天
3. 15分钟内产生的log不能超过250MB

为了回避此问题，Salesforce提供了Class和Trigger的Debug Log级别自定义功能。官网点此。
启用这个功能，可以在Class和Trigger的详细页面，找到TraceFlag，在此设定需要的Debug log级别，(一般全开最详细，或者全关)
自定义完成后，transaction中class和trigger产生log时的级别设定，就会覆盖默认的debug log级别设定。
使用此功能可以极大的减少不需要的log输出，从而避免被随机截断。

但是，System.debug必然不是万能的。

所以在DeveloperConsole中，Salesforce给开发者提供了CheckPoint功能，注意，不是BreakPoint，是CheckPoint。
Checkpoint不同于BreakPoint那样可以互动。只提供了信息查看功能。
就是说，在代码中打上Checkpoint之后，程序执行并不会暂停，而是执行到结束，但Salesforce会将Checkpoint标记位置的内存状态保留下来供开发者查看。
需要值得注意的是，Checkpoint全局只能打5个。

如果代码真的复杂到checkpoint和Debug log都无法搞定，
Salesforce提供了一个真正的Debug工具——Apex Debugger
有了Apex Debugger，Salesforce开发者也可以像Java程序员一样debug了。
不过越强大的武器，限制越多。
Apex Debugger只提供了一个免费的License，并且是全Org通用，就说Production和旗下所有sandbox合起来同时只能有一个人用。

不管使用哪种Debug方式，都应该从设计伊始就避免设计出如此巨大的自定义功能。