单元测试二：为什么的要用单元测试

单元测试的作用：可以更好的校验代码的输入输出预期；重构代码时，可以更大胆的对现有代码动刀子。
单元测试的好处：把你的测试过程写成代码吧，交给机器去跑单元测试；代码可能被频繁改动，每改动一次，都应该测试一次

 

功能代码 + 测试代码

这里的测试代码特指单元测试代码。

• 互相验证
  • 其实对于功能代码和测试代码而言，两者是一个互相验证的关系，也就是“好基友，一辈子+一被子”的关系。
  • 经常有人会问，测试代码不也是代码嘛，那谁来测试啊，答案就是功能代码，不至于出现“测试测试代码”之一说法吧，然后无限递归下去吧。这个疑问的担心是，代码是人写的，难免会出问题，测试代码也是代码，所以自然也难免出问题。
  • 其实这个担心是对的，消除这个担心，一个是借助成熟的单元测试框架，减少各种细枝末节的考虑，只关注测试验证，必然能减少很多犯错，但这只能减少，想要规避是不可能的，但可以事后补救，比如测试代码的错误，导致不应该测试通过的，竟然测试通过了，那么这个时候功能代码必然也出错，这个时候不管有没有发现，就必然是产生问题了，如果被发现了，那么就知错就改呗，找到绕过测试代码的地方，看看怎么修改下测试代码逻辑，是否能测试到这种情况。
• 先写？后写？
  • 有人经常的疑惑就是，我到底是先写测试代码呢？还是写完功能代码再写测试代码呢？这个不好说，感觉看个人习惯吧，我的习惯一般都会是偏向后写，因为很多时候在功能代码没出来前，有些测试代码的测试用例设计很难。
  • 当然一些通用、普遍或者业务逻辑简单的场景写还是可以尝试下所谓“测试先行”的做法的。
  • 这里说的前提，貌似就是由程序员自己负责来写对应的测试代码了。可能有的公司会区分出，开发工程师和测试开发工程师，前者更偏重功能实现代码为主，测试代码为辅；后者更偏重测试代码为主。这个时候，先后也许不那么重要。
• 度的问题
  • 还有人的疑惑就是，到底写多少测试代码才算到头啊？我的想法是，别想了，永远到不了头的。合理的做法是够用就行。
  • 比如用户注册，最起码测试下注册成功的情况吧，然后测试失败的情况吧，当然失败情况一堆，咋办？挑个主流的失败场景呗。
  • 如果那些边边角角测试不到咋办？别急着一口气吃撑胖子，慢慢补呗，毕竟你主要任务还是实现那个注册功能，测试也会服务于这一点的。但如果你非得一天把罗马城建完，那我也无话可说，有钱、有时间的人就是牛X。
  • 其实我这说了也白说，度的问题，往往是自己慢慢体验的。

测试代码只是零散的测试片段，要把这些测试集合起来，必然还是要配合测试框架、工具自动化之类的。还是那句话，机器不会偷懒。

 

场景

说了这么多，来说个简单的单元测试应用场景吧：

1. 天哪！我写的代码竟然有一个bug！
2. 吭哧吭哧，调式了半天，终于找到了触发条件，一个很诡异的条件。
3. 咚咚！打断一下，切换到传统场景，这个时候一般就继续吭哧吭哧修复功能代码了，然后提交修复，perfect！感觉很有成就感。
4. 叮叮！忽略刚才的打断，goto到2。这么诡异的条件，太容易被忽略了，还是加段测试代码保险一下吧，免得别人修改代码时候也碰到这种坑爹的情况。
5. 吭哧吭哧写了个单元测试代码，来模拟刚才的条件触发，果然测试不通过！
6. 吭哧吭哧修复完功能代码。
7. 执行单元测试模拟条件触发，测试通过，看来修复还是有效的。

其实这个好处就是能以后避免出现这种条件触发的bug被再次引入，至少有了个保障。

 

示例

实际点，用代码说话才是王道。随便找几个开源项目的代码提交，来说明下单元测试的是怎么做的吧：

• Python
  • Python的某个版本中，SSL库对HTTPS处理有个缺陷：http://bugs.python.org/issue5103
  • 看下官方的修复：http://hg.python.org/cpython/rev/ce4916ca06dd/
  • 可以看到有：功能代码 + 测试代码 + 还有必要的文档更新，这样才算一次完整的提交。
• Django
  • https://github.com/django/django/commit/25f2acfed0fc110f88abbfffb5c5c62a76670db0
  • 类似，功能代码 + 测试代码 + 还有必要的文档更新。

其实这里体现了一个软件配置管理（SCM）的深刻理解，就是： 一切开发行为，统一在版本仓库中进行自动记录。

也就是传统的手工跑一边功能代码的单元测试这个测试行为没有被记录在版本仓库中，而单元测试代码则很好的帮助记录了，这里2个示例更好的还有对应文档的更新。

 

单元测试其实只是众多环节的一小部分，或者说是一个起点吧，按顺序演变：

• 测试框架。有了成熟的框架，必然事半功倍。
• 集成测试。其实也是借助各种成熟工具，来帮你做代码层面的集成测试吧。
• 自动测试。机器帮你跑测试了，自然就自动了。
• 持续构建。每次提交代码构建也好，每日构建也好，跑一遍单元测试一般都是很重要的一个步骤吧。
• 持续发布/交付。前面基础打得好，自动化程度足够高，这种层面的持续就不是梦想了。
• 高效高质量迭代。注意不仅仅是高效，而且是高质量。
• 质量可靠的软件、服务、项目、产品。其实这个才是我们的目的不是吗？单元测试只不过是达到我们目的的工具箱中的众多工具之一。