Understanding Test Data

各位同学，咱们现在看到这一页，讲的是Apex 测试数据一些非常重要的性质。你写测试的时候，数据到底怎么回事，这个必须搞清楚，不然测试结果会跟你预想的完全不一样。 咱们一条一条来看，我尽量用大白话解释。 首先第一条，测试数据是临时的，它根本不会真的写进数据库。你看啊，咱们测试方法里插入的那些账户、联系人、机会，当下好像存在了，断言也能查得到，但只要测试方法一跑完，这些数据就自动回滚了，就好像从来没发生过一样。你不需要去写任何删除清理的代码，平台自己就帮你把痕迹抹干净了。这非常方便，也保证了生产数据库的干净。 接下来这条更关键。从 API 版本 24.0 开始，测试方法默认是有一道“数据隔离墙”的。啥意思呢？就是你的测试代码，它看不到组织里本来就存在的那些业务数据，比如你生产环境里已经有的客户、商机，测试里是查不到的。它只能看到自己在测试方法里当场创建的那些数据。这就像是把测试关在了一个只有它自己搭的小房间里，外面真实世界它看不见。 但是这条规则有个例外：像用户、简档、组织这些设置或元数据对象，它是可以访问到的。因为这些是基础配置，不是日常交易数据，所以允许测试直接使用。比如你测试里可以直接用 [SELECT Id FROM User WHERE ...] 来获取一个已有的用户，这个没问题。 那假如你测试的是一个更高版本的类，但它底层调了一个老版本的类呢？也就是如果 API 24.0+ 的测试调用了一个用 API 23.0 写的类里的方法，怎么办？规则很简单：谁调用谁来限制。虽然是那个老类的方法在跑，但数据访问的限制还是按调用者、也就是测试自己的版本来执行。也就是说，那个老类原本也许能看到组织数据，但在新版测试的调用下，它也一样得遵守隔离墙，同样看不见组织数据。这个要小心。 还有一点经常踩坑的，就是在测试里发出的 Visualforce 请求。这种请求是会打破数据隔离的。因为 Visualforce 页面运行的时候，可以访问组织的完整数据，你如果在测试里模拟一个 Visualforce 请求，它就能跳出去看到真实数据了。那测试的可靠性就受影响了，所以一般不建议在测试里搞这种操作，或者你得特意准备对应的数据。 最后一点，特别提醒，就是使用“数据筒仓”测试策略时，千万不要在测试数据和真实组织数据之间共享记录 ID。比如你不能从组织里拿一个真实客户的 ID，然后在测试里直接指着它说“给我更新这条记录”，因为测试里根本看不见那条记录。你更不应该让测试故意生成一个和组织已有 ID 相同的记录，然后做跨数据的关联，这会导致混乱。测试就只能操作它自己新建的那些 ID，老老实实在它的小隔间里玩。 好，这一页的重点就是这些。大家记住：测试数据是临时的、隔离的，别想着靠已有数据，自己动手创建，自给自足才最稳。有什么问题咱们再讨论。