unit-testing - ODT(观察驱动测试)有哪些好处和缺陷？

Question

我们刚刚发现 whitepaper “观察驱动测试:是的，代码正在做你想做的事。顺便说一下，它还做了什么？”，并且很感兴趣。

但是，谷歌似乎并没有透露太多关于它在实践中是如何工作的(1，2)。那里的一切似乎都来自供应商，Agitar .

有没有人将 ODT 作为 TDD 和 CI 的补充流程来实现？

如果是这样，请分享您遇到的一些好处和陷阱……我们很乐意从您的智慧中受益。

Answer 1

观察驱动测试或多或少是 Agitar 对使用其产品的术语。几年前我评估了 Agitar 的产品。它不会取代正常的单元测试，但会与它一起工作。尽管有一个使用它的过程，就像所有事物一样，但我不认为它是 TDD 或 CI 或 CD 级别的过程——它就像使用静态分析工具一样，就像测试一样。尽管如此，它还是非常强大和有趣的。

它的核心功能是不变检测，Agitar 称之为搅拌。它会找到您代码中的所有方法，并使用一组自动确定的参数值执行每个方法。它在如何选择参数值方面很复杂:它会做一些相对明显的事情，比如对整数使用 MIN_VALUE、-1、0、1 和 MAX_VALUE，但它也能够观察现有的测试代码运行并收集有趣的值以在搅拌时使用。它明确支持具有外部依赖性的对象，例如 JDBC 连接。

在使用所选参数值运行一个类的所有方法后，Agitar 对参数值、方法返回值和字段值进行观察(候选不变量)。它将它们呈现给用户，用户可以将它们提升为不变量，这将在未来的搅拌运行中进行测试，或者更改代码以使观察变得不可能。例如，Agitar 可能观察到调用一个参数为 null 的方法会导致该方法抛出 NullPointerException。更改代码以处理 null 将在以后的运行中消除该观察结果。

Agitar 可以根据其观察结果生成 JUnit 测试。我不知道与仅维护 Agitar 工具中的不变量相比有什么优势。

我没有购买 Agitar 的产品，但我仍然非常尊重我所看到的，并会在合适的环境中再次考虑它(Java，对防弹代码的强烈业务需求)。它发现了我使用 TDD 开发的代码中的错误，这些代码的行和分支覆盖率接近 100%。更好的是，观看它的工作改进了我对单元测试的看法!

关于陷阱:它是 Java 特有的，专有且昂贵。此外，因为它是一个如此彻底的工具，并且它的观察与实现细节相结合，所以要维护 Agitar 对正在积极开发的程序的看法需要付出很多努力(比维护验收/集成/单元测试套件更重要) .

这是我发现的关于激动的最佳快速介绍:http://www.agitar.com/downloads/demos/agi_demo/agiDemo.html .这里有关于前身和相关系统的有趣阅读:http://plse.cs.washington.edu/daikon/pubs/ .另外，ScalaCheck似乎实现了一个类似但简单得多的过程。