Question

简单地说，我能用Boost.Test 1.58实现这样的效果吗？

BOOST_AUTO_TEST_CASE(my_test)
{
    auto context = construct_context();
    auto values = context.get_values();
    BOOST_REQUIRE(!values.empty()); // #1: breaks whole test case
    for(auto&& value: values)
        // Note: there's no 'BOOST_TEST_SCOPE' in Boost.Test, it's a pseudo-code
        BOOST_TEST_SCOPE("enum values") // Kind of "named nested scope", runs like '[&] ()` lambda
        {
            BOOST_CHECK(!value.empty()); // #2 Performs like normal check
            BOOST_REQUIRE_EQ(value.sub_value(), complex_computation(value)); // #3 Will break only to #4, not the whole case
        }; // #4 Where nested scope ends
    BOOST_CHECK(other_check(values)); // #5 will be run when loop ends -
                                      // because #3 will fail only BOOST_TEST_CASE block
}

更新

我宁愿避免参数化和数据驱动的测试。它们似乎都需要对我的测试代码进行复杂的重新洗牌，将它的一部分放在不同的位置，处理状态和传递，而不是简单和线性的程序功能。

Answer 1

如果您不能使用数据驱动的测试，我建议只编写循环，可选择使用BOOST_TEST_MESSAGE发出“元”信息，以便您可以看到循环的开始位置：

for(auto&& value: values) {
    BOOST_TEST_MESSAGE("enum values: " << value);
    BOOST_CHECK(!value.empty()); // #2 Performs like normal check
    BOOST_REQUIRE_EQ(value.sub_value(), complex_computation(value)); 
}

Answer 2

您拥有的构造类似于将测试套件与测试用例进行比较。您在boost.test中嵌套了测试套件，根本不需要手动注册。您还可以使用强大的方法为测试套件定义fixtures，包括也可以方便的fixture decoration。测试套件中的测试用例可以是parametrised测试用例。

我认为所有这些构造都使代码清晰易于维护，但我显然有偏见。

使用Boost.Test运行嵌套的子测试用例

2 个答案: