老李分享：单元测试的 5 个错误 老李分享：单元测试的 5 个错误

老李分享：单元测试的 5 个错误

 

当我第一次据说可使用框架好比JUnit来进行单元测试的时候，我惊叹这真是一个简单而强大的概念。它取代了随机测试，使你能够保存你的测试代码，并按照须要随时运行它们。按照个人理解，关于单元测试并无多少产生误解的可能。可是过去的几年中，我确实见过几种或多或少不太正确的单元测试使用方式。这里按照重要程度，列出5条:

 

1. 跟协做逻辑一块儿来测试算法。若是跟协做逻辑代码分离开来，那么算法逻辑是最容易测试的(参见选择性单元测试 – 代价和好处)。不然在你的逻辑被测试以前，你就不得不先进行诸如经过任务队列提交一个任务之类的工做。 任务队列部分只会使事情变得复杂。除非你想测试任务队列自己，不然你就应当把调用run方法时所执行的逻辑剥离开来，并对它进行单独测试。那样，不管是编码仍是测试都会更易于编写和管理。

2. Mock测试太多。也许单元测试的最大好处就是它迫使你编写可以独立测试的代码。也就是说，你的代码会变得模块化。当你把你要处理的对象的周围的一切都模拟了，就没有什么能迫使你去把各部分分离开来。你会发现这样写出的代码，你很难在外围添加独立的部分 – 由于全部东西都纠缠在一块儿。Bill Wake最近发推说: ”真是讽刺 – 模拟测试框架越强大，你在改进设计时所感觉到的压力就会越小。”

3. 不使用断言。有时我会看到一些测试，里面建立了一个对象，调用了一些方法，而后，就没有而后了。也许它是在循环里这样作的，并且在建立和调用上会有些差别。可是，却没有用断言来作任何检查。这就彻底失去了意义 – 没有检查你的代码是否按照预期进行工做的。固然，代码是运行了，可是仅此而已。若是抛出了一个异常，咱们会注意到它，可是却不会验证其它任何事情。

4. 在测试代码中遗留print语句。我把这视为手工测试的后遗症 – 你但愿看到对象的值来判断它们是否正确。可是全部的检查都应当使用断言来完成。若是单元失败了，你也能看到它，由于这个测试也会失败。当测试经过时，什么也不该当打印出来。在编写测试代码时，使用print语句有时是有用的。可是在须要用print的地方应当设置一个标志位，用来在进行测试的时候屏蔽它。

5. 查看日志信息，而不是运行结果。 还好这并不广泛，可是我却见过一个很是有能力的开发人员这么干过。要知道，真正重要的是方法的运行结果，而不是日志中都打印了什么，由于即便代码中有错误，测试也可能会经过。好了，说的很明白了。

后面3个问题都很容易规避。头2个问题则须要付出更多努力，可是会获得良好分离的代码。