我对单元测试的理解

我将写单元测试代码看做开发的一个工具，就像ide起同样的做用，帮助咱们开发。

写单元测试最好在第一个接口函数完成时就开始写，不然代码多了，就不原意写了。

有框架能够用框架，没框架自已写个简单的程序验证一下自已的假设便可。

我通常c++用gtest和gmock，c#用nunit，java用junit。用法都很简单。mock会麻烦一些，找个教程多看一看就差很少了。主要是对单元测试的理解。

其实不少开源项目都是写一个简单的小程序，printf出相关数据看是否与自已指望的一致。

真正写起来，单元测试代码量不多，不然说明你接口设计的有问题。这就引出单元测试代码的做用，帮助你写出好的接口。

好的接口要功能明确，职责单一，若是一个接口干多件事，你的单元测试就无法写，由于太多了。若是一个接口的单元测试函数超过四五个，就建议你好好考虑是否接口设计的有问题，对这个接口甚至整个功能作什么是否真的想清楚了。包职责是否单一，是否合理的分层。若是未合理分层，也会致使单元测试代码膨胀。

有些时候你会遇到单元测试很差写，过分依赖mock才能写测试代码，这是由于代码的耦合度高的原故，应该让代码尽可能独立，低耦合。减小对其它模块或者环境的依赖。例如你在一个接口中依赖了系统时间，这个单元测试就比较难写，倒不是难写代码，而是你运行时总不能等待系统时间吧。这时就有了对系统环境的依赖，最好的办法是将时间做为参数传进去。固然用mock也能够解决难测的问题，但这不是正确的解决办法。

写单元测试代码还有助于你写出符合开放封闭元则的代码。很简单，你通常不会将一个原本应为private的函数写成public的，由于须要测试啊。

若是你关注了接口，真正考虑好了接口，功能的定位，符合了开放封闭原则，也不大须要重构，或者说在开发阶段就已完成大部分重构了。

由于代码进行了很好的分层，之后既使功能有改动，通常状况下也不会影响全部层。

若是是写c或c++代码，你也不会多引入头文件，由于单元测试代码，不少时候要自已写makefile，你多引入了头文件，makefile会变复杂。

你也不会写超长的函数，由于超长的函数通常很难测试。

你也不会过分使用继承与虚函数，而会考虑组合，由于继承与虚函数也很难测。

其实不少时候单元测试代码比想像象中的少，写起来也比想象中简单，前提是你想明天接口要作什么，接口设计好。

可是单元测试不容易上手，我以为主要是难以想明白：把写单元测试代码当作测试而不是开发辅助手段；什么tdd一堆的概念弄得人晕头转向；总以为写单元测试代码很高大上，须要框架支持才能作；总以为单元测试代码会不少，会是实际代码的好几倍；老是在代码完成后才写单元测试代码，这时发现单元测试代码根本无法写，接口设计不合理，耦合度高等；必定要团队总体提倡才好写，不然生产率低。这些想法都不必。

千万不要等到全部代码都完成再写单元测试代码，由于这时候写单元测试代码意义已经不大，并且不少状况下，这时候已经无法写单元测试了，已完成代码极可能存在接口设计不合理，耦合度高等问题，且单元测代码量会很大，望而生畏。同理，也不要为别人写单元测试代码，也不要别人替你写单元测试代码。

其实写单元测试代码对总体时间来讲不是延长了，而是缩短了，由于通常一个功能要经过，须要询试几回，包括编译（通常要所有编译），发布，手动验证，有些时候还须要配置环境，而单元测试代这些均可以自动化。并且单元测试代码已经提早协助作了重构。代码质量获得了提升。被测试人员测出的bug也会有所减小。

不少人开始考虑写单元测试代码，是以为单元测试代码对重构有帮助，主要是指后期重构。开始也是这样理解。真正开始写了后发现，对代码的前期（全部代码完成前）帮助最大。有时我甚至会前期写单元测试代码，后期就直接忽略了（由于以为有时候小的改动对逻辑没影响，单元测试代码也就懒得同步了），固然这不是好习惯。

还有，不少人说单元测试是白盒测试，讲求代码覆盖率。这也是不少人以为单元测试代码难写写的缘由之一。其实单元测试不该该讲代码覆盖率，而应该是功能或逻辑覆盖。某一个接口函数，是干什么的，有几种可能性，都考虑到了，写了相关的测试函数，也就能够了，不用讲代码覆盖率，不过这些覆盖了，代码也就覆盖了，不然可能有废代码。还有，从接口函数角度看，我以为是黑盒的。并且容许里面的实现变更，只要测试函数都能经过便可。

写单元测试仅仅是个开发的辅助工具，不是非它不可，写不写都不用纠结。个人建议是早点动手实践，在实践中反思。没有真正想通，或以为没用，就先放一放。

写单元测试也有不少限制，修改已有代码很难写单元测试代码。数据库操做，界面我不知道怎么写单元测试。

编辑于 2017-08-20

著做权归做者全部