ODT（观察驱动测试）有哪些优点和缺点？
我们刚刚看到白皮书“观察驱动测试” ：是的，代码正在做你想做的事。顺便说一句，它还做了什么？”，并且很感兴趣。
然而，谷歌似乎并没有透露太多关于它在实践中如何工作的信息（ 1、2）。那里的所有东西似乎都来自供应商 Agitar。
有人实施 ODT 作为 TDD 和 CI 的补充流程吗？
如果是这样，请分享您遇到的一些好处和陷阱...我们很乐意从您的智慧中受益。
We just came upon the whitepaper "Observation Driven Testing: Yes, the code is doing what you want. By the way, what else is it doing?", and were intrigued.
However, Google doesn't seem to reveal much about how it works in practice (1, 2). Everything out there seems to be from a vendor, Agitar.
Has anyone implemented ODT as a complementary process to TDD and CI?
If so, please share some of the benefits and pitfalls you've encountered with it... we'd love to benefit from your wisdom.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
观察驱动测试或多或少是 Agitar 使用其产品的术语。几年前我评估过 Agitar 的产品。它不会取代正常的单元测试，而是与其一起工作。虽然使用它有一个过程，就像所有事情一样，但我不认为它是 TDD、CI 或 CD 级别的过程——它就像使用静态分析工具一样，就像测试一样。尽管如此，它仍然非常强大且有趣。
其核心功能是不变检测，Agitar 将其称为“搅动”。它查找代码中的所有方法，并使用一组自动确定的参数值执行每个方法。它在如何选择参数值方面很复杂：它做了相对明显的事情，例如对整数使用 MIN_VALUE、-1、0、1 和 MAX_VALUE，但它也能够观察现有测试代码的运行并收获有趣的值以在搅动时使用。它对具有外部依赖项（例如 JDBC 连接）的对象提供显式支持。
使用所选参数值运行类的所有方法后，Agitar 对参数值、方法返回值和字段值进行观察（候选不变量）。它将它们呈现给用户，用户可以将它们提升为不变量，这将在未来的搅拌运行中进行测试，或者更改代码以使观察变得不可能。例如，Agitar 可能会发现，调用一个参数为 null 的方法会导致该方法抛出 NullPointerException。更改代码来处理空值将在将来的运行中消除该观察结果。
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 似乎实现了一个类似但简单得多的过程。
Observation-Driven Testing is more or less Agitar's term for using their product. I evaluated Agitar's product several years ago. It doesn't replace normal unit testing but works alongside it. Although there is a process to using it, as there is to everything, I wouldn't consider it a process on the level of TDD or CI or CD -- it's as much like using a static analysis tool as it is like testing. Nonetheless it is very powerful and interesting.
Its core functionality is invariant detection, which Agitar calls agitation. It finds all of the methods in your code and executes each with an automatically determined set of parameter values. It is sophisticated in how it chooses parameter values: it does relatively obvious things like using MIN_VALUE, -1, 0, 1 and MAX_VALUE for ints, but it is also able to watch existing test code run and harvest interesting values to use when agitating. It has explicit support for objects with external dependencies like JDBC Connections.
After running all of a class's methods with the chosen parameter values, Agitar makes observations (candidate invariants) about parameter values, method return values and values of fields. It presents them to the user, who can either promote them to invariants, which will be tested for in future agitation runs, or change the code so the observation becomes impossible. For example, Agitar might observe that calling a method with one parameter being null causes the method to throw
NullPointerException. Changing the code to handle the null will eliminate that observation in future runs.Agitar can generate JUnit tests from its observations. I don't know of any advantages that offers over just maintaining the invariants in Agitar's tool.
I didn't buy Agitar's product, but I still have great respect for what I saw and would consider it again in the right environment (Java, strong business need for bulletproof code). It found bugs in code that I had developed with TDD and which had nearly 100% line and branch coverage. Even better, watching it work improved how I think about unit tests!
Regarding pitfalls: it is specific to Java, proprietary and expensive. Also, because it is such a thorough tool and its observations are coupled to implementation details, it would take a lot of effort to maintain Agitar's view of a program that was being actively developed (more than maintaining the acceptance/integration/unit test suite).
This is the best quick introduction to agitation that I found: http://www.agitar.com/downloads/demos/agi_demo/agiDemo.html. There is interesting reading on a predecessor and related systems here: http://plse.cs.washington.edu/daikon/pubs/. Also, ScalaCheck appears to implement a similar although much simpler process.