你需要什么样的测试工具?

最确定的是,每个项目的列表中的所有内容:

• 文件名
• 行号
• 测试覆盖率
• 开始时间和结束时间
• 和/或总时间(这对我来说比前两项更有用)
• 诊断输出,如 你得到的和 你所期望的。

从我的头顶上看除了这组测试我想知道

• 组名

编写测试必须非常容易,运行测试也同样容易。对我来说,这是测试工具最重要的特性。如果有人必须启动一个GUI或通过一堆箍来编写测试,他们不会使用它。

一组任意的标记-因此我可以将测试标记为,例如“integration,UI,admin”。

(你知道我会要求这个的,不是吗:-)

对于你所说的,我要补充:

• 方法/函数/类名
• 覆盖率计算工具,但有例外(不要计算这些方法)
• 要求必须存在容易分析测试结果的方法

任何类型的诊断输出- 尤其地 失败是关键。如果测试失败,您不希望总是在调试器下重新运行测试以查看发生了什么-输出中应该有一些clude。

我还希望看到关键系统变量(如内存或硬盘空间)的前后快照,因为这些也可以提供很好的线索。

最后,如果对任何测试使用随机种子,请将种子写入日志文件,以便在必要时可以复制测试。

我希望能够连接和嵌套分流。

能够识别单个测试的唯一id(uuid,md5sum)——例如,在将测试结果插入数据库时使用,或者在bug跟踪器中识别它们,以便QA能够重新运行单个测试。

这也使得在产品的多个版本的整个生命周期中,可以从一个构建到另一个构建跟踪单个测试的行为。这最终可能会允许“历史性”事件(新员工、产品发布、硬件升级)与此类事件导致测试失败的配置文件之间存在更大规模的关联。

我还认为TAP应该通过一个专用的侧通道发射,而不是与stdout混合。我不确定这是否在协议定义的范围内。

• 测试步骤不能分组(只有分组成几个测试脚本;但是为了在我们的软件中运行所有测试,我需要至少多一个级别的分组,这样一个测试步骤就可以通过类似“DB connection”->“Reconnection test”->“test step#3”)来标识)
• 看到预期输出和实际输出之间的差异是有用的;我要么将diff打印到stderr(作为注释),要么实际启动一个图形diff工具
• 协议和工具必须真正独立于语言。例如,到目前为止,我只知道Perl用于运行测试的“证明”工具,它仅限于运行Perl脚本

最后,测试输出必须适合作为轻松生成HTML报告文件的基础,该文件非常简洁地列出成功的测试,为失败的测试提供详细的输出,并使快速跳入IDE到失败的测试行成为可能。

• 可选的ascii彩色输出,绿色表示正常,黄色表示挂起,红色表示错误

• 在测试报告末尾的一个摘要,其中列出了将运行各个测试的命令

• • 出了问题

TAP的扩展理念:

1..4
ok 1 - yay
not ok 2 - boo
ok 3 - yay #json:{...}
ok 4 - see my json

能够附加一个json注释。。。 -可以被现有代码安全地忽略 -易于生成、分析和读取复杂类型