HttpCalloutMock — Full Test Example (cont.)

同学们，我们来看这张幻灯片讲的重点，它其实是关于我们怎么测试对外部服务的调用——也就是在Apex里做HTTP Callout的测试。 假设你写了一个类叫CalloutClass，里面有个方法叫 getInfoFromExternalService，这个方法负责真正去调用外部的、比如第三方的天气接口或者支付接口。但是在测试的时候，我们不能真的去连外网发请求，因为那样测试会变慢、不稳定，而且Salesforce也不允许在测试里做真实的callout。那怎么办呢？我们就需要“模拟”这个外部服务。 这里的关键就是在测试类里使用 Test.setMock。在调用 getInfoFromExternalService 之前，我们先调用 Test.setMock，告诉Salesforce：接下来的callout不要真发出去，而是用我自己写的一个模拟响应来代替。这个模拟响应其实是一个实现了 HttpCalloutMock 接口的类，我们经常叫它“Mock类”。你可以把模拟想象成一个假的收件箱——当你的代码试图向外发请求时，Salesforce直接把这个假收件箱里的响应丢给你，让你以为真的从外部拿到了数据。 设置完模拟之后，测试类就可以放心地调用 getInfoFromExternalService 了。这个方法以为自己发了个请求，但实际上它拿到的是我们在模拟里设置好的响应。这时候，我们就需要去验证一下返回的结果，确保是模拟里塞进去的那个响应，而不是系统编造的别的什么东西。 具体验证什么呢？幻灯片上说了三个点：检查 Content-Type 头、检查响应正文、以及状态码。比如你的模拟响应里设定了状态码200，正文是 “success”，Content-Type 是 “application/json”，那你的测试类就得断言收到的响应状态码也是200，正文完全相同，头信息也匹配。这样，我们既保证了模拟本身工作正常，又能让测试覆盖到callout那部分代码，满足部署要求的代码覆盖率。 所以简单总结一下流程：一个方法专门负责真正的HTTP Callout；另一个测试类里，先设好模拟的假响应，再调那个方法，最后对拿到的响应做断言，验证头、正文、状态码。这样一圈走下来，我们就既有信心的把代码部署上去，又不会在测试时受外部服务的限制。 大家在练习的时候，可以试着给不同的外部接口写模拟，多感受一下这个模式。好了，这张幻灯片的核心就是这些，有任何疑问随时提出来。