Questions tagged «test-coverage»

7
您应该使用单元测试来测试什么?
我刚大学毕业,下周要去上大学。我们已经看到了单元测试,但是我们并没有太多地使用它们。每个人都在谈论他们,所以我想也许我应该做些。 问题是,我不知道要测试什么。我应该测试一下普通情况吗?边缘情况?我怎么知道一个功能已被充分覆盖? 我总是有一种可怕的感觉,尽管测试可以证明某个功能在特定情况下可以工作,但是证明该功能在一定时期内是完全没有用的。

11
路径覆盖范围是否可以保证找到所有错误?
如果测试了程序的每条路径,是否可以保证找到所有错误? 如果没有,为什么不呢?如何解决程序流程的每一种可能的组合,如果存在的话却找不到问题? 我毫不犹豫地建议可以找到“所有错误”,但这也许是因为路径覆盖不切实际(因为它是组合的),所以从未经历过? 注意:本文提供了我考虑的覆盖类型的快速摘要。

7
代码覆盖突出显示了未使用的方法-我该怎么办?
我的任务是增加现有Java项目的代码覆盖率。 我注意到,代码覆盖率工具(EclEmma)强调了一些从未在任何地方调用的方法。 我最初的反应不是为这些方法编写单元测试,而是向我的生产线经理/团队强调它们,并询问为什么要从那里开始使用这些功能。 最好的方法是什么?为他们编写单元测试,或者质疑为什么要在那里?

4
如何大幅提高代码覆盖率?
我的任务是让遗留应用程序处于单元测试之下。首先介绍一下应用程序的背景知识:这是一个600k LOC Java RCP代码库,存在以下主要问题 大量代码重复 没有封装,大多数私有数据都可以从外部访问,一些业务数据也成为单例,因此不仅可以从外部更改,而且可以从任何地方更改。 没有抽象(例如,没有业务模型,业务数据存储在Object []和double [] []中),因此没有OO。 有一个很好的回归测试套件,一个高效的质量检查团队正在测试和发现错误。我知道如何从经典书籍(例如Michael Feathers)中对其进行测试的技术,但这太慢了。由于存在工作正常的回归测试系统,因此我不怕积极地重构系统以允许编写单元测试。 我应该如何着手解决问题以快速获得覆盖范围,以便能够向管理人员展示进度(实际上是从JUnit测试的安全网中开始赚钱)?我不想使用工具来生成回归测试套件,例如AgitarOne,因为这些测试不会测试是否正确。


1
测量Java 8代码的条件覆盖范围是否有意义?
我想知道自Java 8出现以来,当前使用Java的工具来衡量条件代码覆盖率是否还没有过时。使用Java 8 Optional,Stream我们通常可以避免代码分支/循环,这使得在不测试所有可能的执行路径的情况下轻松获得很高的条件覆盖率。让我们将旧的Java代码与Java 8代码进行比较: 在Java 8之前: public String getName(User user) { if (user != null) { if (user.getName() != null) { return user.getName(); } } return "unknown"; } 以上方法有3条可能的执行路径。为了获得100%的条件覆盖率,我们需要创建3个单元测试。 Java 8: public String getName(User user) { return Optional.ofNullable(user) .map(User::getName) .orElse("unknown"); } 在这种情况下,分支是隐藏的,我们只需要进行一次测试即可获得100%的覆盖率,无论哪种情况我们都将进行测试。我相信,尽管仍然存在相同的三个逻辑分支。我认为这使有条件覆盖范围统计这些天完全不可信。 测量Java 8代码的条件覆盖范围是否有意义?还有其他工具可以发现未经测试的代码吗?

7
如何使用图形结构对代码进行单元测试?
我正在编写(递归)代码来浏览依赖关系图,以查找依赖关系中的循环或矛盾。但是,我不确定如何进行单元测试。问题是我们主要关心的问题之一是将对可能出现的所有有趣的图结构进行代码处理,并确保所有节点都将得到适当处理。 尽管通常100%的行或分支覆盖率足以确保某些代码可以工作,但即使100%的路径覆盖率,您仍然会有疑问。 因此,如何为测试用例选择图形结构,以确保其代码可以处理您在真实数据中发现的所有可能的排列。 PS-如果重要的话,我图中的所有边都标记为“必须具有”或“不能具有”,并且没有琐碎的循环,并且任何两个节点之间只有一条边。 PPS-此附加问题声明最初由问题的作者在以下评论中发布: For all vertices N in forest F, for all vertices M, in F, such that if there are any walks between N and M they all must either use only edges labelled 'conflict' or 'requires'.

2
我如何知道我是否有足够的单元测试范围来删除集成测试?
我正在使用旧系统(这意味着它是在没有测试的情况下编写的)。我们试图通过编写集成测试来测试某些系统,这些集成测试从外部测试功能。 这使我有信心重构代码的某些部分,而不必担心会破坏它。但是问题在于这些集成测试需要一个部署(2分钟以上)和很多分钟才能运行。而且,它们很难维持。它们每个都覆盖了数千行代码,当其中一个中断时,可能需要花费数小时来调试原因。 我最近为这些功能更改编写了很多单元测试,但是在提交之前,我总是做一个新的部署并运行所有集成测试,以确保我不会错过任何东西。至此,我知道我的单元测试和某些集成测试与它们的测试重叠。 我怎么知道我的良好单元测试足以覆盖不良的集成测试,以便我可以删除该集成测试?


4
单元测试内部组件
您在多大程度上对类/模块/包/等的内部/私有组件进行单元测试?您是否对它们进行了测试,还是仅测试了与外界的接口?这些内部方法的一个示例是私有方法。 例如,想象一下递归下降解析器,它具有从一个中央过程调用的几个内部过程(函数/方法)。到外部世界的唯一接口是中央过程,该过程采用字符串并返回已解析的信息。其他过程解析字符串的不同部分,可以从中央过程或其他过程中调用它们。 当然,您应该通过使用示例字符串调用外部接口并将其与手动分析的输出进行比较来测试外部接口。但是其他程序呢?您是否会分别测试它们以检查它们是否正确解析了其子字符串? 我可以想到一些论点: 优点: 测试越多越好,这可以帮助增加代码覆盖率 通过向外部接口提供输入,某些内部组件可能很难提供特定的输入(例如,边缘情况) 更清晰的测试。如果内部组件具有(已修复的)错误,则该组件的测试用例可以清楚地表明该错误位于该特定组件中 缺点: 重构变得非常痛苦和耗时。要更改任何内容,即使外部接口的用户不受影响,也需要重写单元测试。 某些语言和测试框架不允许这样做 您对此有何看法?

3
您将如何测试Google Maps的“获取路线”功能?
(我想这将是一个很好的面试问题,但就我而言,这比这更为实际。) 我们有一个庞大而复杂的应用程序,可以对数十种化学成分之间极其漫长而复杂的化学反应过程进行建模。我们正处于为应用程序设计验收测试的阶段,但是对于可能的测试路径数量之多,我们有些畏缩。在我看来,我们的情况非常类似于Google Maps开发团队在其“获取路线”功能中测试路线规划算法时必须面对的情况。显然,他们无法测试(验证和验证)所有可能的路线。那么,他们如何使自己的应用程序在任何情况下都能运行的信心? 而且由于我不希望知道他们是如何做到的,所以让我问您:您将如何设计一个具有足够代码覆盖率的测试套件,以使自己确信给定的应用程序是健壮的,而这在实际上是不可能的探索整个系统的每条潜在路径? 我正在寻找的原则是您可以用来将棘手的问题分解成较小的,易处理的部分,这些部分的总和提供了令人满意的整体估计:“我无法测试所有内容,但我可以对此进行测试,这个和这个-就足够了。” 考虑到实际的预算/时间限制,我并不是在寻找一种“证明是正确的”方法,而是一种审慎的方法。 (我将Google Maps示例用作箔纸,以寻求尽可能具体的答案。)

10
有关如何反驳代码覆盖率质量参数的任何工具/建议
现在,我知道人们会认为这个问题重复或被问过很多次,在这种情况下,我希望获得与相关问题的链接以及我的问题的答案。 我最近在代码覆盖方面与某些人意见不一致。我有一群人希望我们的团队基于100%的覆盖率并不意味着良好的质量测试以及良好的代码质量就完全放弃代码覆盖率的研究。 通过推销“代码覆盖率”可以告诉我尚未确定的内容的论点,我可以进行回退,并帮助我们专注于这些领域。 (以上已经在类似这样的其他SO问题中以类似的方式进行了讨论-https: //stackoverflow.com/questions/695811/pitfalls-of-code-coverage) 这些人的论据是-然后,团队会做出反应,迅速创建质量低下的测试,从而浪费时间,同时又不增加明显的质量。 在理解他们的观点的同时,我正在寻找一种方法,通过引入更健壮的工具/框架来照顾更多的覆盖标准, 从而使代码覆盖更可靠(Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc)。 我正在寻找的建议是将这样的代码覆盖率工具和实践/过程结合在一起使用,这可以帮助我在对建议感到满意的同时反驳此类争论。 我也欢迎根据您的经验/知识如何提出反对意见提出的任何评论/建议,因为尽管主观,但是代码覆盖率使我的团队更加意识到了代码质量和测试价值。 编辑:为了减少对我对典型代码覆盖范围弱点的理解的困惑,我想指出的是,我并不是指 Statement Coverage(或执行的代码行)工具(有很多)。实际上,这里有一篇很好的文章介绍了所有错误之处:http : //www.bullseye.com/statementCoverage.html 我不仅在寻找语句或行覆盖率,而且还在寻找多个覆盖率标准和级别。 请参阅:http : //en.wikipedia.org/wiki/Code_coverage#Coverage_criteria 这个想法是,如果一个工具可以根据多个标准告诉我们我们的覆盖范围,那么它将成为对测试质量的合理自动化评估。我绝不是要说线路覆盖率是一个很好的评估。实际上,这就是我提出这个问题的前提。 编辑: 好的,也许我对它的预测太过夸张了,但是您明白了。问题在于以统一/一致的方式在所有团队中设置流程/策略。人们普遍担心,您如何确保测试质量,如何在没有任何措施的情况下分配保证的时间。因此,我喜欢具有可测量的功能,当使用适当的流程和正确的工具进行备份时,它将使我们能够提高代码质量,同时又知道不会浪费时间在浪费性的流程上。 编辑:到目前为止,我从答案中得到了什么: 代码审查应涵盖测试以确保测试质量 “测试优先”策略有助于避免事后写出的测试仅增加覆盖率% 探索涵盖测试标准的替代工具,而不仅仅是声明/行 分析覆盖的代码/发现的错误数量将有助于理解覆盖的重要性并提供更好的案例 最重要的是,请信任团队的投入以做正确的事并为自己的信念而战 涵盖的区块/测试数量-值得商but,但具有一定价值 感谢您迄今为止的出色回答。我真的很感激他们。此功能比具有强大功能的头脑风暴要好几个小时。

2
单元测试和集成测试的代码覆盖率报告是分开的,还是两者都有一个报告?
应该为单元测试和集成测试提供单独的代码覆盖率报告,还是为两者提供一个代码覆盖率报告? 其背后的想法是,代码覆盖率使我们能够确保我们的代码已被尽可能多的测试所覆盖(无论如何,现在无论如何机器)。 拥有单独的报告更方便我们了解单元测试未涵盖的内容以及集成测试未涵盖的内容。但是这样一来,我们看不到总覆盖率。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.