我眼中的单元测试

　　实际上我接触单元测试的时间并不算短，大三的时候就有一门课是讲测试的，我很早就知道什么是单元测试，要怎么设计测试用例。当然我不打算在博客中炫耀自己的理论知识，所以不要期待我在博客中介绍边界值法、逻辑覆盖、路径覆盖什么的。但把单元测试真正用在实际项目中，还是去年的事情，就算做毕业设计，我也没有写单元测试。

　　去年我工作的团队开始推广单元测试，当然我不认为单元测试是银弹，它不可能解决软件质量上的所有问题，也不可能让软件质量有一个质的飞跃，但它的确对提高软件质量有相当大的促进作用。首先它能保证各个独立的程序单元是符合预期的，这是保证整个系统能符合预期地运行的基础；其次，一个测试友好的程序必定也是一个低耦合的程序，低耦合对于调试和后期维护的好处，写过程序的人应该都懂。实际上去年令我觉得最有成就感的事情就是把单元测试应用到实践中了，可是说这是少数能直接应用我所学的理论的场景之一（PS：我不是说学校的理论没用哈，实际上支撑我工作的大部分还是学校学到的理论，只是很少理论能直接应用于实践）。

　　单元测试由于是一个测试过程，所以很少程序员会重视，甚至一些理解不深的人还会把单元测试看作是测试环节的一部分，我就曾经听到过测试的负责人问开发的负责人，推行单元测试测试方面需要给予什么支持。单元测试和测试人员有什么关系？可以说一点关系也没有，实际上单元测试不是测试环节应该做的事情，而是开发环节就应该做的事情，这是程序员的义务，程序员是有义务证明你写的程序是正确的。但现在能真正把单元测试好好执行的团队凤毛麟角。

　　WeiboSpider中的单元测试

　　在WeiboSpider刚启动的时候，我就决定把单元测试作为项目的一部分，把它和主程序放在同等重要的地位。作为开源项目，我觉得单元测试比非开源的项目来得更重要。一旦项目开源，谁修改你的代码就变得不可控了，如果对方是一个牛人，不仅把你的代码重构得相当优雅，还帮你修复了几个十分隐蔽的bug，你会觉得这是上帝派人下来打救你了；但要是对方是一个水平一般，而且又粗心大意的程序员呢？他在你良好运行的程序中改出bug了怎么办？你怎么迅速地定位错误？如果他曲解了你意图或程序设计的初衷，私自改变了程序运行的逻辑，你能发现吗？所以Oracle当初拿掉MySQL的单元测试，在开源界反响还是很大的。对于MySQL这种规模这么大，而且成熟的开源软件，拿掉单元测试对于修改和重构程序都是无比困难的。

　　单元测试提供了一个很好的检验标准和检验方法，程序哪怕一点点偏离了预想的运行方向，单元测试都能发现（当然前提是测试用例足够严谨），所以良好的单元测试不仅是发现程序bug的工具，更是程序设计者设计思想的表达，所有修改程序的人，要么严格地按照程序最初设计者的思路修改程序；要么先理解好程序最初设计者的设计，再改进设计。

　　尽管在开发WeiboSpider的过程中，我没有使用TDD，但我依然坚持每增加一个模块，完成编码后都会为它写上单元测试。这样能保证我每个完成的模块，局部都是正确的。因为WeiboSpider开发的周期可能很长，而初期开发的大部分代码都是相对隔离的，无法集成起来测试。如果等到集成的时候才开始测试代码，调试代码就会变得很困难，特别是调试几个月前写的代码，当时的思路都未必记得了。因此尽管到目前为止写单元测试的工作量大概占了我整个开发工作量的1/3，但我依然会坚持下去，为了程序更好地维护，还有后续开发效率的提升。

　　Python中的单元测试

　　Python在其标准库中，就已经有一套较为完整的单元测试框架了，这对于降低这个语言单元测试的学习成本和版本管理成本是相当有帮助的。比如Java，标准库中不提供单元测试的框架，尽管现在主流是用JUnit，学会JUnit应该能应付大部分Java项目的单元测试了，但总有非主流的存在。另外不同版本的JUnit必定会有些微小的差别，这样一个项目除了对Java的版本进行限定，对单元测试框架的版本也需要进行限定。对于第三方库的版本管理问题，一直是一个比较头疼的问题。而对于已经包含进标准库中的Python单元测试框架，则不存在第三方库的问题了，对于一个特定版本的Python环境，单元测试框架也是固定的。

　　Python的单元测试框架也是独立于IDE的。这个对于大部分编程语言来说应该都是理所当然的吧，但有一个例外，它就是.NET。微软提供的官方.NET单元测试框架是耦合在Visual Studio中的。对于大部分场景这样的确没啥问题，因为没有几个.NET程序员不是用VS作为开发工具的，但如果要在服务器上自动跑单元测试呢，比如持续集成环境，难道我还要在服务器上装一个VS？所以开源社区也为.NET提供了第三方的单元测试框架，比如比较流行的NUnit——JUnit的兄弟版本。但其实这样的话又回到了上一段提到的问题了。