单元测试应该测什么

1. 覆盖所有代码

单元测试应该全面覆盖项目开发的代码，但是依赖的第三方代码不应该被测试。
凡是非本项目开发的代码，都可以认为是第三方代码。
比如，我们项目依赖别的部门提供的存储服务，连接此服务需要使用他们提供的一个脚本，而这个脚本存放在我们的util目录中。像这个脚本，就是所谓的第三方代码。

我用下面这段话来说服领导将这个脚本从测试中移除。

我们的开发是建立在完全信任它的基础上的。既然完全信任它，我们又何必针对它建立单元测试呢?即使它真的有问题，那也应该是提供它的团队应该负责的事情。

后来我把我上面的意思做了一个归纳：

只应该测试本项目生产的代码。

2. 一次只测试一个单元

比如有三个函数， a,b,c 。 a调用b和c。
如果我们测试a，就应该模拟b和c，而不是让a直接调用b和c。
这样能保证测试失败的时候，准确的找到错误的原因。反之，可能是b和c的问题，但是a的测试失败了，就会误导测试人员。
有些项目中，测试代码是先于开发代码完成的。当我们想测试a的时候，可能b和c还没有实现，这个时候，也是需要模拟b和c。
保证一次只测试一个单元，能够最大限度内聚测试逻辑，反映待测试单元的特性。

3. 正反测试

单元测试应该测试函数输出是否符合预期。预期应该包含两方面。当输入在正常范围时，返回的正常预期；当输入在非正常范围时，返回的错误预期。

举个例子：
有个函数，叫 ‘煎鸡蛋’。这个函数有如下功能：
* 当接收一个鸡蛋，就返回一个煎蛋；
* 当接收一个石头，就返回一个错误，内容是，‘俺不会做石头’；
* 当什么都不输入时，就返回错误，内容是，‘对不起，巧妇难为无米之炊’。

我们测试的时候，就依据这三个功能点，进行测试。

煎鸡蛋(鸡蛋).should.equal(煎蛋);
煎鸡蛋(石头).should.equal(俺不会做石头);
煎鸡蛋(鸡蛋).should.equal(对不起，巧妇难为无米之炊);

测试一定要覆盖函数的所有功能点。

4. 测试驱动开发

其实上面的例子已经接近测试驱动开发的概念了： 先设计煎鸡蛋函数，想好它的功能点，然后声明函数，对功能点一一编写测试脚本。在编写脚本的过程中，可能还会想到其他的功能点，比如，如果一次放入多个鸡蛋，怎么处理。这样我们逐渐完善测试脚本的过程中，功能逐渐的丰富起来。然后，依据测试脚本，编写煎鸡蛋的实现。最后，测试，发布。