APP重构之路:引入单元测试

一、为什么要引入单元测试

在开发过程中我们会遇到这样一些问题：

• 面对需要重构庞大的模块代码时无从下手
• 修改了一处地方却在另一处地方引发了新的bug
• 扩展新功能的同时导致旧代码出现bug
• 在测试人员难以覆盖到的基础功能接口出现了bug
• 出现了一种难以重现的特殊边界条件触发的bug

另外我们也许还会遇到一些这样的模块：

• A模块依赖于B模块的结果，但是B模块尚未开发完成
• 模块状态过于复杂，手工测试需要耗费大量时间
• 模块业务与时间节点相关，手工测试难以覆盖

这个时候也许能够利用经验和丰富的debug技巧来解决这些问题，但是很多时候我们的处理并不完美，因为我们缺少了一个规范，在编码过程中难以顾及其他模块的影响，这个时候，我们就需要引入单元测试。

二、单元测试的价值

可维护性增强

当在对代码进行修改时，利用单元测试就能够清晰的知道是否破坏了老的业务逻辑，这样大大减少了回归出错的可能性。而当我们从测试那里获得了一个bug时，就可以通过测试用例去还原，当我们这个测试通过后，这个bug也就解决了，而且这个bug fix的测试用例也保证了这个bug以后不会再次出现。

降低重构难度

有了单元测试的保障，我们可以比较大胆的进行重构设计，而单元测试也会成为重构时很好的一