What to Test in Apex

同学们，这节课我们聊聊 Salesforce 里怎么写测试才够“扎实”。 Salesforce 官方其实给了非常实用的建议，它不是让你随便写几个断言就完事儿了，而是希望你的测试能真正模拟现实世界中用户的各种操作。 我们一条一条来看。 首先，你要针对 ，单个记录的操作， 来写测试。什么意思呢？比如用户只修改了一条客户信息，那你的测试就要确保在这种情况下，程序能正常工作。 然后，别光测一条，还要测 ，批量操作，。尤其是 1 到 200 条记录这个区间。因为在 Salesforce 里，触发器、批次作业经常会一次处理很多记录，如果你只测一条，可能代码在批量时直接报错，而你还不知道。所以一定要覆盖到批量的场景。 接下来是 ，正向和负向行为，。正向就是一切正常，用户做了正确的事，程序给出正确的结果。负向就是当用户做错事时，你的程序能正确阻止，并且给出，正确的验证错误消息，。你还得专门写测试来断言：哎，这个负向操作确实抛出了异常，而且异常信息就是我设计的那句话。这才能确保当用户输错数据时，他看到的是清晰友好的提示。 还有一点特别重要：，要模拟受限制的用户场景，。很多代码对系统管理员跑得顺顺利利，但换成普通用户、权限不够的时候，可能就崩溃了。所以你要用不同 Profile 的用户去跑测试，看看他们在自己的权限下是不是也能正常使用。 最后，我单独强调一个技术细节：，条件和三进制运算符，。在 Salesforce 的代码覆盖率要求里，一个 `if` 条件，或者一个 `? :` 三进制表达式，如果你只测了条件为真的那条路，它是，不完全算被覆盖，的。你必须同时执行正分支和负分支，也就是既测条件成立，也测条件不成立，这行代码才会被标记为完全覆盖。所以设计测试数据时，要故意制造两种走向的数据，确保所有逻辑分支都被走过。 这样一套组合拳下来——单条、批量、正负行为、错误消息、限制用户、全分支覆盖——才能真正保证你的应用不论碰到什么现实场景，都能稳得住，不出乱子。 好，这节课就到这里，下次咱们动手练起来。