测试代码时你会犯的 11 个错误

我遇到的大多数开发人员都不怎样热衷于测试。有些会去做测试，但大多数都不测试，不愿意测试，或者者勉而为之。我喜欢测试，并且比起编写新的代码，愉快地花更多的时间在测试中。我认为，正是由于专注于测试，我才可以花更少的时间来编写新的代码或者修复bug，并且非常有成效。

假如你不确定要不要编写测试或者者并不常写测试，那么，下面这些内容将指导你往一个更好的方向发展。

image

1.没有测试

我们很容易毫无起因地掉入这个圈套。从现在开始，制定计划增加测试到你现在正在解决的代码中，并增加测试到将来的项目中。

2.没有从项目一开始就启动测试

我们很难再回过头去增加测试，并且可能需要改变架构才能增加测试，这样做最终将需要你花更长的时间才能产出可信任的代码。从一开始就在项目的生命周期增加测试可以节省时间和精力。

3.编写失败的测试

TDD方法的普及将红—绿—重构的理念带到软件测试世界。这个理念常常被误认为应该“通过编写一个失败的测试开始”。其实并非如此。在写代码之前创立测试的目的是定义系统的正确行为应该是什么。在许多情况下，它是一个失败的测试（红色表示），但它可能会通过一个非决定性的或者未实现的测试来表示。

4.担心未实现测试

软件开发中的一个大问题就是，代码和任何关于系统实际上应该做什么的文档之间的沟壑。通过拥有一个名称中明确定义你最终想要实现的预期行为的测试，你将从测试中得到肯定的价值，即便将怎样写测试目前还不得知。

5.没有很好地命名测试

命名软件这件事出了名的很难做好，这同样适用于测试。关于如何命名测试有几种流行的商定。无论你使用哪一种都没有关系，只需你能够一贯使用，并精确形容正在测试什么。

6.让测试做太多事情

又长又复杂的名字通常说明了你想同时测试多件事情。单个测试应该只测试一件事情。假如失败了也应该在代码中注明是什么地方出了错。你没有必要为了知道代码中出了什么问题而查看是哪部分测试失败。这并不意味着你不应该在测试中有多个断言，但这些断言应该紧密相关。例如，一个查看订单解决系统输出，并确认输出中能否有一个单一项目以及它能否包含具体项目的测试，是ok的。但一个验证相同系统的输出的测试，既创立一个特定项目，又记录到数据库中，还发送确认电子邮件，就不行了。

7.没有实际测试代码

经常可以看到测试新手创立过于复杂的模型以及不能实际测试代码的设置程序。他们可能会验证模拟代码能否正确，或者者模拟代码能否和真正代码做相同的事情，或者没有任何断言而只是执行代码。这样的“测试”都是浪费力气，特别是假如它们的存在只是为了提高代码覆盖率水平的话。

8.担心代码覆盖率

代码覆盖率的理念很崇高，但往往实际价值有限。知道运行测试的时候有多少代码被执行应该是有用的，但由于它不考虑正在执行代码的测试的质量，因而就变得没有意义。代码覆盖率在它数值非常高或者非常低的时候，是挺博人眼球的。假如非常高，就表明，比起带来的价值，过多的代码可能正在被测试。非常低的代码覆盖率表明有可能代码的测试不够。由于这样模棱两可的意思，有的人就不知道单一片段的代码能否应该进行测试。我用一个简单的问题来明确这一点：代码能否包含重大的复杂性？假如包含，那么你需要少量测试。假如没有的话，你就不需要。测试属性访问器不过是白费时间。假如它们失败的话，那么比起你正在写的代码，你的代码体系出现了少量更根本的问题。假如你不用看一段代码，就立即知道一切，那么它就不重大。这不仅适用于代码，也适用于你写代码。假如我们在任意点重访代码，那么它就需要测试。假如在现有代码中发现过bug，那就说明这一块的代码对其复杂性没有进行充分的测试。

9.着眼于一种类型的测试

一旦你开始测试，很容易只纠结于一种风格的测试。这是一个错误。只用一种类型的测试，你就不能充分测试系统的所有部分。你需要单元测试来确认代码的各个组件能否能够正确工作。你需要集成测试来确认不同组件能否能够协同工作。你需要自动化UI测试来验证软件能否可以如预期使用。最后，你需要为任何不容易自动化的部分和探究性尝试进行手动测试。

10.着眼于短期测试

来自于测试的价值大多数会随着时间的推移而取得。测试不应该只存在用于确认事情能否正确写入，而应该随着时间的推移继续起作用，并且对于代码库做其余的改变。有回归错误或者新的异常，那么测试应该重复运行以尽早发现问题，这将意味着错误和异常可以更快，更便宜和更容易被修复。没有变化（人为错误）可自动和快速执行的测试，是为什么编码测试如此有价值的起因。

11.作为一个开发者，依靠于别人来运行（或者编写）测试

假如不运行，那么测试几乎没有价值。假如测试不能被运行，那么即可能遗漏bug。自动运行的测试（作为一个持续集成系统的一部分）是一个开始，但项目的任何一个人都应该能够随时运行测试。假如需要特殊设置，机器，权限，或者配置来运行测试，那么这些将成为执行测试的壁垒。开发者需要能够在检查代码之前就运行测试，因而他们需要能够访问并有运行所有相关测试的权力。代码和测试应保持在同一个地方，并且所需的任何设置都应该写好脚本。关于这个方面我见过的最坏的例子是一个做的很糟糕的项目，在这个项目中测试人员的子团队定期取走开发人员正在解决的代码副本，他们修改代码以便他们能执行一系列测试，但这些测试是开发人员在特殊配置（无证）的机器上所无法访问的，而后测试人员再发送一个很大的邮件给所有的开发人员以说明他们找到的问题。这不仅是一个坏的测试方式，而且也是团队工作的糟糕方式。不要这样做。代码能够正确执行是专业开发人员的部分属性。要保证代码的精确性，方法是使用伴随它的适当测试。依靠其余人为你写的代码编写测试和运行测试，不会帮助你成为一个专业的开发人员。

假如以上这些都不属于你的情况，那么恭喜你！继续保持开发稳健又有价值的软件。

假如上面有少量的确发生在你身上，那么是时候做少量改变了。

最后，给大家推荐一个前台学习进阶内推交流群685910553（前台资料分享），不论你在地球哪个方位，
不论你参与工作几年都欢迎你的入驻！（群内会定期免费提供少量群主收藏的免费学习书籍资料以及整理好的面试题和答案文档！）

假如您对这个文章有任何异议，那么请在文章评论处写上你的评论。

假如您觉得这个文章有意思，那么请分享并转发，或者者也可以关注一下表示您对我们文章的认可与鼓励。

愿大家都能在编程这条路，越走越远。