专栏首页java一日一条测试代码时你会犯的 11 个错误

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

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

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

1.没有测试

我们很容易毫无原因地掉入这个陷阱。从现在开始,制定计划添加测试到你现在正在处理的代码中,并添加测试到将来的项目中。

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

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

3.编写失败的测试

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

4.担心未实现测试

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

5.没有很好地命名测试

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

6.让测试做太多事情

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

7.没有实际测试代码

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

8.担心代码覆盖率

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

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

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

10.着眼于短期测试

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

11.作为一个开发者,依靠于别人来运行(或编写)测试

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

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

如果上面有一些确实发生在你身上,那么是时候做一些改变了。

本文分享自微信公众号 - java一日一条(mjx_java),作者:收听我

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-08-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 编写更好的 Java 单元测试的 7 个技巧

    测试是开发的一个非常重要的方面,可以在很大程度上决定一个应用程序的命运。良好的测试可以在早期捕获导致应用程序崩溃的问题,但较差的测试往往总是导致故障和停机。

    哲洛不闹
  • Android 中构建快速可靠的 UI 测试

    让我一起来看看 Iván Carballo和他的团队是如何使用Espresso, Mockito 和Dagger 2 编写250个UI测试,并且只花了三分钟就运...

    哲洛不闹
  • 为什么要测试,测试是如何令人更快乐的?

    我曾经是一个不测试主义者,因为我看不到测试的价值。然后,我试了一段时间,变得对它深信不疑。我收集了一些经验,当然还远远不够。这篇文章总结了一些我知道的以及我认为...

    哲洛不闹
  • 产品不同测试阶段的测试分析

    软件测试应该贯穿软件产品的整个研发周期,在不同的研发阶段,会有不同的测试方法和手段跟进。进行不同的测试来保障产品的质量。软件测试的分类有很多种,本文章就以一个...

    小老鼠
  • 功能测试面试题(一)

    01. 为什么要在一个团队中开展软件测试工作?   因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这...

    用户7466307
  • 网上看到的面试题,我忍不住吐槽....

    张树臣
  • 软件测试思想浅谈

    张树臣
  • 测试分析设计总结

    Tester_Jun
  • 《软件测试52讲》读书笔记 —— 如何做好测试计划

    确定测试范围一般在测试需求分析完成后进行,所以确定测试范围的过程在一定程度上也是对测试需求分析的进一步检验,有助于在早期阶段发现潜在的测试遗漏;

    小菠萝测试笔记
  • 测试基础篇(二)—— 面试挺常见

    ================================================================

    小菠萝测试笔记

扫码关注云+社区

领取腾讯云代金券