单元测试(Unit Testing) – 对已有代码添加单元测试

我最近接触单元测试比较多，有一些心得，希望能通过写几个专题帮助自己总结一下，这些专题不会花很多篇幅介绍单元测试的基础知识，而是偏重在实际应用中单元测试经常遇到的一些困难。

 

第一篇我想说说对已有代码添加单元测试的解决方案。虽然其中的代码是类似Delphi的，但是并不难懂，应该不会成为其他程序员阅读的障碍。

 

对单元测试有了解的朋友知道，单元测试能够尽早的发现程序中的bug，大大提高代码的第一时间质量，并且可以强制重构（refactoring）代码，辅助项目管理等等。大家一定也知道，单元测试能帮助重构代码的原因是因为单元测试需要代码有非常好的逻辑结构，很多时候，为了测试一段代码，自然而然的就迫使你把代码合理的组织和分离。

 

这时，问题就来了，对于很多已有的项目，逻辑未必清晰，结构未必合理，很多人想为这些项目添加单元测试，怎么办呢？最直接的办法恐怕是重新组织代码，然后进行测试。然而，大家都知道，在绝大多数情况下，这种做法是不太现实的，很少有人愿意动一些不是自己写的、又已经“正常”工作了很长时间的代码，虽然逻辑混乱得像一锅粥，但是只要它还能正常运行，who cares? 而事实上，很多时候，我们为已有代码添加单元测试的目的并不是要完全的测试这些代码的每一个角落，因此，第一时间对代码进行重写对于我们的目的来说可能过于“昂贵”了。

 

打个比方，我们有一个输入单据的窗口，已经被用户使用了3年了，应该说这个窗口的大部分功能还是比较稳定的，但是有一个模块是例外。这个模块主要负责根据用户的输入进行一些自动的计算，比如当用户输入单价和数量后，自动在“总金额”一栏填上前面二者的乘积，随着时间的推移，用户需要更多的自动计算功能，比如向银行贷款，涉及到利息的计算，而如果允许分期付款，也有另外的利息计算，如果允许抵押证券来购买，情况更是复杂多变，但是，由于初期设计的不合理，使得这一部分经常出问题。于是，你决定要给这个模块添加单元测试，每一次添加新的计算规则，都要进行充分的单元测试，解决了大部分用户的要求以后，才交付用户使用。

 

可是，当你分析这个模块代码的时候，发现由于当时设计的原因，很难将其分离出来单独测试。比如，你看到的代码可能是这个样子：