避免无用的测试
现在来说什么时候没必要写单元测试，这里提到的单元测试也同样包括不遵循 TDD 原则所编写的测试，比如说先写代码后写测试的情形。
到底什么是无用的测试，我说了其实不算，只有写代码的人才真正知道。但如果你刚接触测试，确实不清楚哪些该写哪些不该写，那么我有两个建议：
1、只写必要的测试：什么是必要的测试我已经在 TDD 的时机那一节讲过了，如果你不知道要写哪些测试，就先从此处开始；
2、只写关键的测试：有时候必要的测试你写不出来，身边又没有人辅导，那也勉强可以跳过。但是关键性测试不要省。所谓关键性的测试，就是你所写代码里的核心逻辑；再换句话说就是如果一切顺利，它至少能够做到（或者不要去做）的那件事。这就意味着你可能忽略了一些边界条件的处理，而且你也不知道该怎么处理，但是你至少保证了最重要的那条路线是可以走通的。将来重构的时候，这条关键路线就像夜空中的北极星一样能确保你不至于茫然无措。
如果在构造关键性测试用例的时候你发现你很难触碰到那一点（比如说前置条件你不会在测试用例里处理），那么很大的可能是你的这个单元过于复杂了，这是一个极好的立时重构信号。你可以尝试把要触碰的那一点逻辑抽取出来单独测试。这样一来你至少做到了把核心逻辑分离出来，其他的代码就算再糟糕重构起来也会轻松得多。
至于无用的测试，虽然无法在此一一列举，但也可以总结几条：
1、不要去测试语言的核心库和／或标准库函数：如果你的代码简单到就调用了一句标准库函数，那还浪费什么时间去编写测试啊，这些代码都是久经考验的。虽然也有语言本身错误的小概率事件发生，但由于标准函数的处理过程你触碰不到（常常深埋于虚拟机中或调用系统底层接口）所以你的测试对你自己的代码丝毫没有帮助。（当然，如果您是专家级程序员则不在此例，说不准您就是等着解决这个问题呢）
2、不要去测试框架的基础类或工具方法：道理和第一条类似，知名的框架都有很完备的自身测试，否则你也不敢用不是？如果你确信是框架自身出了问题，你的测试更应该去应用在框架本身上，说不定你可以做出个补丁为该项目做出贡献。
顺手举个例子：你继承了某框架的 Model 层，然后在里面定义了检查其实例的某一属性是否为空的验证（使用框架自带的验证方法，而不是自己编写的）。这种情况就没有必要测试这个检查是否生效，除非你这个类在初始化的时候返回的是其他类的实例……你项目组里有这么无聊的人吗？
3、不要去测试外部依赖的有效性：这是初学者常常陷的坑，而且往往把自己折磨到不行。
这里有两个问题：第一，如果你的测试一定需要外部依赖，你首先应该考虑伪造它，而不是在 A 的测试里先检查 B（也就是说，你的测试目标是 A，为了完成这个测试用例，你需要用到 B 并且 B 的某种特性一定要成立，这是先决条件，于是你不得不写一句断言先测试这件事情，然后才能测试真正的目标 A）。如果你能伪造一个 B，叫 B'，那么 B' 不一定非要和 B 完全一样，只要它能表现出来恰好满足本次测试用例的特征就足够了。这样事情就会变得单纯的多。
其次，即使你无法伪造 B（基本上是因为不会），那么你至少应该把对 B 的特性测试转移到 B 自己的单元测试中去。
最后还有一种测试是“无用”的，那就是从来只见它绿没见过它红的测试。你自己都没意识到这种测试可能从头到尾都没有测试任何代码！这也是 TDD 强调先红后绿再重构的原因之一，你至少应该在最开始让测试用例失败一次，否则等测试数量变多以后再去分辨就来不及了。另外重构完了也最好手动破坏一下代码（比如随便往里面打几个无意义的字符）诱使测试报错，以确保测试真的覆盖到了目标代码。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
