代码覆盖通用功能/参数?

时间:2008-12-08 21:31:17

标签: automated-tests code-coverage generics

我正在为我的应用程序编写一些代码覆盖率。现在,我知道代码覆盖率是一种与您创建的测试类型以及您希望进行代码覆盖的语言相关联的活动。

我的问题是:有没有办法做一些通用的代码覆盖?像我们一样,我们是否可以运行一组功能/测试用例(以及针对被测应用程序的更多特定测试),以获得代码覆盖率为10%或更多的代码?

更像是,如果我希望构建一个代码覆盖的框架,那么制作通用代码的最佳方法是什么?是否有可能使某些功能自动化或通用化?

2 个答案:

答案 0 :(得分:1)

由于以下几个原因,我不确定通用覆盖工具是否属于圣杯:

  1. 覆盖范围不是目标,而是一种工具。它告诉你代码的哪些部分没有完全被测试命中。它没有说明测试有多好。
  2. 生成的测试无法猜测代码的语义。为您生成测试的框架只能从阅读代码中扣除意义,这本质上可能是错误的,因为单元测试的整个要点是查看代码是否实际上与您的意图相似。
  3. 因为自动化框架会产生人工覆盖,所以你永远不能告诉他们一段代码是通过适当的单元测试来测试的,还是通过框架进行表面测试。我宁愿将未经测试的代码显示为未覆盖,所以我解决了这个问题。
  4. 你能做什么(我已经完成;-))是为测试Java bean编写一个通用测试。通过反射,您可以针对Java bean的Sun规范测试Java bean。断言equals和hashcode都是实现的(或者都没有),看看getter实际上返回了你用setter推送的值,检查所有属性是否都有getter和setter。

    对于实现“可比较”的任何事情,你都可以做同样的基本技巧。

    它易于操作,易于维护并迫使您拥有干净的豆子。至于其他的单元测试,我试着专注于首先测试重要部件,然后进行测试。

    覆盖范围会给人一种虚假的安全感。常识不能自动化。

答案 1 :(得分:0)

这通常通过将静态代码分析(Coverity,Klockwork或其免费模拟)与动态分析相结合,通过对仪表化应用程序(分析器+内存检查器)运行测试来实现。不幸的是,这很难实现测试算法的自动化,大多数工具都是能够记录流量/密钥/信号的“记录器” - 取决于域并重放它们(最小的更改/替换,如会话ID /用户/等)