一提到TDD(测试驱动开发)，似乎第一感觉都是：理想很美好，现实很骨感。有各种难言之隐无法在实际工作中应用TDD。开发人员好像永远都有各种理由不写测试。今天想给大家分享一个最近我所在的一个项目中的经历，我发现其实TDD的思想就伴随我们平时工作中。
最近的一个项目涉及到用户老系统到新系统的数据迁移工作，开发人员编写了一个迁移程序完成这个工作。但是如何能保证最后所有数据迁移是符合和客户预先定义的规则呢？可能你会说我们程序写的就是按照规则呀！跑完了没有错误就是证据。确实是这个道理，不过开发人员应该都知道，很多时候我们并没有在写code的同时验证所有情况，更何况验证每一条迁移数据，而是把这个工作交给测试人员(原因嘛有很多，就不在这里一一列举了，你我都懂的)。而测试人员也很为难，因为客户生产环境的数据其实是无法人工完成验收的，他们也无法保证本地验证通过生产环境就一定没有问题。
其实我们可以想一下，如果自己是测试人员而不是开发人员，如何应对这种情况呢？或者说没有测试人员配合你，必须自己完成开发和测试的场景，你该如何办呢？再或者如果你是开发人员，你期待测试人员如何来测试你写的功能并覆盖所有情况呢？我想最有信心的方式肯定是用测试用例覆盖所有已知的业务逻辑，同时验证所有数据。这样心里才有底。那么用我现在的例子，如何验证呢？我思考有如下步骤：
- 将我知道的所有数据迁移规则都会罗列出来，例如数据映射关系，数据合并和拆分规则，数据转换规则等。
- 为每一个规则只做迁移前的数据，同时整理出来迁移后的期待数据集合。通过运行迁移程序后，看迁移后数据库数据是否和预期数据集合一致。
- 反复操作第2步，直到所有已知规则都验证通过。
- 将上面三步的验证应用到实际客户每一条数据上。也就是覆盖所有数据的校验。
可以看到前三步还能用人工完成，第四步必须要使用自动化工具了。是不是挺简单的一个思考过程？基于这个思路，我想到了一个经典工具——Excel。如果能够将迁移前后的数据按照一对一的方式导出到Excel中，将数据对比的验证逻辑通过Excel的公式来实现，那岂不就实现自动化的验证了。实际我们也真的是这么做的。效果也符合预期。
在这个过程中我和测试人员还发现了开发遗漏的一些情况。这让我不禁思考，如果把上面的测试步骤放到开发功能之前，也就开发在写实际code之前，做一些基于迁移规则的数据和预期结果，并在完成开发工作后验证是否结果符合预期。这样这种遗漏规则的情况可能会更早被发现。而随着新的情况被发现，配合修改code补充新的测试，循环往复，我们自己对这部分逻辑会越来越有信心。而再想一下，这不就是测试先行的思想吗？不就是用测试的思路来驱动开发功能——TDD吗？
其实平时的工作中，我们做什么事情都需要一个验收的标准，而这些标准就是对工作完成度的一个通过标准。同时因为有规则也就代表了我们知道预期结果。如何能够实现预期，就是我们具体要做的工作。这和TDD的思路不约而同。我们只是要在编写Code的时候加入验收code的预期结果。
开发同学们还在找接口不写测试吗？想想我下面这个问题你如何回答：“你如何证明你写的程序符合预期？”
践行敏捷实践，让工作变得更美好。欢迎给我留言，交流落地经验。
