这是我在
我想这样去逼近白盒测试的一个回帖。
gigix 写道
tianxinet 写道
code review 是最好的白盒测试方式之一。
视图覆盖测试所有代码是不值得滴。
http://www.infoq.com/news/dangers-code-coverage
不错。也看了John Casey的原文。这应该是John Casey重构“Maven's assembly plugin”后写的一篇blog。
刚好,结合John Casey的原文谈下自己的一些看法:
引用
when you're seeking confidence through testing, perhaps the worst thing you can do is to look at a test coverage report.
开篇,John Casey说明不要把注意力集中到coverage report,他在文中逐步给出了理由。
我完全同意,code coverage有必要做,但到底多高的覆盖率是好,100%,90%?一个应用中的很多代码可能根本没必要去coverage,只对关键代码编写详细的测试代码就够了。至于什么是关键代码,可能是最重要的功能,或逻辑最复杂的部分...,一个成熟的团队完全有能力根据具体情况进行判断。
引用
Recently, I spent quite a bit of time refactoring Maven's assembly plugin. I'm sorry to say that I was fooled when I started by the siren song of coverage reporting,.........the plugin had a suite of tests that were so rigidly constructed that even fixing a simple bug would result in hours of debugging the test cases to find out what assumption had been violated.
当开始重构“Maven's assembly plugin”时,John Casey被coverage report愚弄了。修正一个简单bug就要花数小时的时间去检查原来的test case。
我不能怀疑“Maven's assembly plugin”老版的开发者水平很糟糕,只能怀疑用于单元测试的test case写的太复杂了(或许就是试图追求过高的覆盖率?),而且已经本末倒置了,到底是要测试function code还是test code?
引用
I planned to move the existing tests to an undisclosed location for safe keeping , then construct a completely new suite of tests to focus on small, specific units of the new plugin's implementation..........As I went, I planned to use the coverage report to mark my progress, and let me know how much I had left to do.
John Casey抛弃了原来的测试代码,重新写了针对少量的、特定单元的测试代码。不过John Casey还是要做coverage report。
我绝对赞同这种做法,只对必要的unit编写详细的测试代码。而相对coverage我认为code review的效果更好,一个团队一起对代码进行code review,这样白盒测试的效果要比依赖coverage report好。这也使团队保持沟通(而且是在开发过程中就代码质量持续沟通),对代码质量有更一致的认知。考虑到有些开发是单独完成的,并没有一个团队,所以只做coverage report也是可行的。John Casey也没有说明他的coverage是什么级别的,line coverage?method coverage?class coverage?我认为配合code review,method coverage对多数情况已经足够(不排除有特殊情况)。
......but by this time I was badly shaken. I had the coverage numbers, but I was starting to see that they weren't telling me the whole story.
......I stopped looking at the report, ......to capture real-world use cases, and test whether they were supported properly.
John Casey开始怀疑coverage report并最终停止关注它,转而去捕获real-world的use case。
过度依赖单元测试是不好的。我之所以这样说,背景是现在单元测试已经受到了足够的重视,恐怕没有哪个开发者或团队会忽视单元测试(其实我还是不太确定单元测试是否已经受到普遍重视)。比如试图对一个应用的所有代码做line coverage就是”过度测试“(好像没这个术语,表达一下意思吧)。
引用
......In the end, the combination of these two approaches resulted in an easy-to-maintain, comprehensive testing strategy.
......integration testing allowed me to capture error reports directly from users, and put them to the test. This provides a quick way to verify a bug - even at a high level - and gives that all-important direction to the debugging effort.
John Casey最终选择coverage、集成测试平衡运用。
code-world 的 test case(白盒测试代码);
real-world 的 use case(黑盒测试用例);
这两者确实要平衡运用,引用一个对John Casey的回复:" Coverage tests are great at telling you when you don't have enough tests. They're terrible at telling you that you have enough, that they're good enough, etc."
引用
......Bumping the progress bar of your coverage report up to account for a line of code which has been touched by one test is a fatally flawed concept, and it can lead to misperceptions on the parts of managers and developers alike. And, since there is no hard-and-fast rule about how many test passes it will take to test any given line of code adequately, the concept of a coverage report is itself fatally flawed.
这是作者的一个总结,让coverage report统计一个测试是否到达一行代码,是一个有致命缺陷的观点。
没什么说的,我完全赞成。覆盖测试每一行代码真的没多大意义。对有些不必要的代码进行coverage,最大的好处或许只是心理安慰。但没有来自real-world的反馈,这样的心理安慰或信心其实很脆弱。
大家有兴趣可以看看:
Testing: Coverage Reports Considered Dangerous
关于这篇文章的讨论:
Opinion: Code Coverage Stats Misleading
分享到:
相关推荐
1. VS2010的单元测试coverage文件无法通过命令行转换为xml文件。 2. 这里C#代码,读取coverage文件,然后转换为xml文件,非常简单。 converage2xlm的用法: Transform the coverage file to xml file. Coverage2xml...
标题中的“Coverage_function_matlab_Coverage_function_”暗示了我们正在探讨的是关于Matlab中的一种覆盖函数(Coverage Function)的实现。在Matlab中,覆盖函数通常用于模拟信号覆盖范围,例如无线通信网络的信号...
总的来说,Coverage工具对于Python开发者来说是一个不可或缺的辅助工具,它可以帮助他们确保测试的充分性,提高代码质量和可靠性。通过深入理解并有效地使用 Coverage,开发者能够更好地维护他们的项目,确保代码的...
2. **支持多种测试工具**:`gemini-coverage` 兼容多个流行的前端测试库,使得开发者可以在不改变原有测试基础设施的情况下引入覆盖率分析。 3. **可配置性**:该库允许用户自定义覆盖率阈值,当覆盖率低于设定值时...
中国省界coverage文件是一种地理信息系统(GIS)的数据格式,用于表示中国各省级行政区域的边界信息。这种数据在各种地理分析、地图制作、区域...在实际工作中,应确保数据的准确性和时效性,以便进行有效的地理决策。
代码覆盖率关注源代码被执行的彻底程度,包括但不限于语句覆盖率(Statement Coverage)、分支覆盖率(Branch Coverage)、条件覆盖率(Condition Coverage)和路径覆盖率(Path Coverage)。这些覆盖率能帮助验证...
空间数据Coverage的创建,空间数据Coverage的创建
《Python测试覆盖率工具coverage 5.0.3详解》 在Python编程中,测试覆盖率是衡量代码质量的重要指标之一,它能反映出程序中被测试代码的执行情况。coverage工具正是这样一款用于计算Python代码测试覆盖率的利器。在...
PHP_CodeCoverage支持多种格式的报告输出,包括但不限于HTML、XML等。这些报告能够清晰地展示哪些代码已被测试覆盖,哪些尚未覆盖,从而帮助开发者有针对性地改进测试策略。具体的报告样式和格式可以根据实际需求...
**php-code-coverage工具包详解** `php-code-coverage`是一个用于PHP的代码覆盖率分析工具,主要用于测试过程中评估代码被单元测试覆盖的程度。这个工具包是PHP生态系统的一部分,与PHPUnit等自动化测试框架紧密...
无论是在简单的本地开发环境,还是在复杂的zookeeper分布式系统或云原生环境中,coverage都是Python开发者不可或缺的工具。通过持续关注并利用好这类工具,我们可以在编程实践中不断提高软件工程的水平。
《JMockit Coverage:深入解析单元测试覆盖率工具》 在软件开发过程中,单元测试是确保代码质量的关键步骤。而衡量单元测试覆盖率则是评估测试完善度的重要指标。JMockit Coverage,作为一款强大的Java测试覆盖率...
除了基本的使用,`coverage`库还提供了许多高级功能,比如排除某些不希望被测量的代码(例如第三方库),或者配置只关注特定的源代码文件。通过`coverage`的配置文件`.coveragerc`,你可以定制化覆盖率测量的各个...
总的来说,`karma-coffee-coverage`是CoffeeScript开发者进行前端项目测试时不可或缺的工具,它通过与Karma的集成,提供了强大的代码覆盖率分析能力,促进了高效且可靠的测试实践。在`karma-coffee-coverage-master`...
4. **持续集成(CI)**:在持续集成流程中,可以配置coverage来检查每次代码提交后的覆盖率,确保代码质量不下降。 5. **多模块支持**:可以分别计算单个模块或整个项目的覆盖率。 6. **忽略部分代码**:如果有些...
在前端开发领域,开源库是开发者们不可或缺的工具,它们为快速构建、测试和优化应用程序提供了便利。"cake-coverage" 就是一个这样的工具,它专注于前端代码的覆盖率报告,帮助开发者评估和改进他们的测试质量。 ...
Termination of Coverage.pdf
传统上,多数研究聚焦于标量传感器(如温度、湿度传感器等),而摄像头传感器作为一种能够提供更为直观视觉信息的设备,在特定应用场景下具有不可替代的优势。本文主要探讨了摄像头传感器网络中的**屏障覆盖**技术,...
标题中的"PyPI 官网下载 | codacy-coverage-1.3.6.tar.gz"表明这是一个在Python Package Index(PyPI)上发布的开源软件包,名为`codacy-coverage`,版本为1.3.6,且已被打包成`.tar.gz`格式。这种格式是Linux和Unix...
"coverage-3.6.win-amd64-py3.3.exe" 是一个专门为Python 3.3版本设计的库,名为`coverage`,并且是针对64位Windows操作系统编译的。这个库的主要作用是进行代码覆盖率分析。 代码覆盖率是衡量测试充分性的一个重要...