Unit Test Considerations

同学们，今天这节课我们来聊聊Apex测试方法的一些重要限制，这些限制虽然看起来多，但理解了它们，写起测试来就会顺手很多。 首先，从API 28.0版本开始，所有测试方法都必须放在专门的测试类里，不能再随意放在普通类中了。这么做是为了更好地组织代码，让测试和业务逻辑分清楚。 其次，测试方法是在隔离的环境里运行的，所以它不能直接去调用真正的Web服务。如果你想测Web服务相关的逻辑，就得使用模拟调用，也就是我们常说的Mock，来假装有外部服务的返回结果。同样的道理，测试代码里也不能真的发出电子邮件，Salesforce会自动屏蔽掉真实的邮件发送，以免在测试时意外地发出邮件。 再来，测试中创建的数据，实际上并不会真正提交到数据库。测试过程就像一个沙箱，结束之后所有数据都会被自动回滚。所以，你完全不用费心去删除测试数据，Salesforce已经帮你处理好了。但这也带来一个问题：有些记录只有在父记录提交到数据库后才会产生，比如字段历史跟踪或者FeedTrackedChange这种变更追踪记录，它们依赖于真实的提交状态，所以无法在测试里直接创建。遇到这种情况，你只能把验证点放在相关的父记录上。 还有一点容易踩的坑：静态成员变量。你在一个测试方法里修改了某个静态变量的值，下一个测试方法是不会看到这个新值的。因为各个测试方法之间是完全独立的，每次运行都会重新初始化静态变量。 最后，一定要记得检查你的测试代码，确保它不会触碰到Salesforce的调节器限制，像是DML语句的总次数、SOQL查询的行数、CPU时间等等。一旦在测试中超限，整个测试就会失败，这就得不偿失了。 把这些关键的限制牢牢记在心里，你的测试编写就会更稳定、更可靠。好，这个Slide的内容我们就讲到这。