boost::test 的 CppUnit 保护器等效吗？
我使用 CppUnit 和 boost::test 进行 C++ 单元测试。 一般来说，我更喜欢 boost::test，主要是因为自动测试宏最大限度地减少了设置测试的工作量。 但我真的很怀念 CppUnit 中的一件事：注册自己的“保护器”的能力，其实例会自动包装所有运行测试。 （从技术上讲，您安装一个测试“侦听器”，并且可以将每个测试包装在保护器范围内）。
我发现这些在过去对于监视单元测试是否有意外副作用非常有用（例如检查代码是否更改了浮点单元状态标志）。 我在 boost::test 文档，尽管 BOOST_FIXTURE_TEST_CASE 可能最接近。
关于如何在 boost::test 中最好地实现与 CppUnit 保护器相同的效果，有什么建议吗？
（我还没有真正研究过 boost::test 的实现，但如果它是类似 CppUnit 的东西，它必须使用非常类似于保护器本身的东西）。
I've used both CppUnit and boost::test for C++ unittesting. Generally I prefer boost::test, mainly because the auto-test macros minimise the effort to setup tests. But there's one thing I really miss from CppUnit: the ability to register your own "protectors", instances of which automatically wrap all the run tests. (Technically, you install a test "listener", and that can wrap each test in a protector scope).
I've found these invaluable in the past for monitoring unittests for unexpected side effects (e.g checking code hasn't changed the floating-point unit state flags). I can't see any equivalent in the boost::test documentation, although BOOST_FIXTURE_TEST_CASE maybe comes closest.
Any suggestions for how to best achieve the same thing as CppUnit's protectors in boost::test ?
(I haven't really looked into boost::test's implementation yet, but if it's anything like CppUnit it must use something very like protectors itself).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我从未使用过 CppUnit，所以不确定保护器是如何工作的。 您是否正在寻找包装单个测试或整个测试套件的东西？
对于前者，您可以使用您提到的固定装置，但据我了解，固定装置应被视为测试“外部”。 他们设置测试所需的任何内容，然后进行清理。 任何实际的错误测试都应该在测试本身中进行，但可以使用 RAII 轻松实现。 只需定义一个类，在其析构函数中检查您需要的任何内容，然后在测试开始时创建它的本地实例。 由于它首先被构造，所以它最后被破坏，因此它可以轻松检查测试是否没有修改任何意外状态。
如果您希望它在执行所有测试后检查这一点，您可能需要全局赛程
I've never used CppUnit, so not sure how protectors work. Are you looking for something that wraps individual tests, or the entire test suite?
For the former, you could use fixtures as you mention, but as I understand it, fixtures should be considered "outside" the test. They set up whatever the test needs, and cleans it up afterwards. Any actual error-testing should be in the test itself, but can be easily implemented with RAII. Simply define a class which checks whatever you need in its destructor, and then create a local instance of it at the beginning of the test. Since it is constructed first, it gets destructed last, so it can easily check that the test hasn't modified any unexpected state.
If you want it to check this after all the tests have executed, you probably want global fixtures