FIXTURES_REQUIRED

3.7 版本中新增。

指定测试所需的 fixture 列表。Fixture 名称区分大小写,并且不需要与测试名称有任何相似之处。

Fixture 是一种将设置和清理任务附加到一组测试的方法。如果一个测试需要给定的 fixture,那么所有标记为该 fixture 的设置任务的测试将首先执行(对所有测试集执行一次,而不是每个需要该 fixture 的测试都执行一次)。在所有需要特定 fixture 的测试完成后,CTest 将确保所有标记为该 fixture 的清理任务的测试随后执行。使用 FIXTURES_SETUP 属性将测试标记为设置任务,使用 FIXTURES_CLEANUP 属性标记为清理任务。如果 fixture 的任何设置测试失败,则列出该 fixture 在其 FIXTURES_REQUIRED 属性中的所有测试将不会被执行。fixture 的清理测试将始终执行,即使某些设置测试失败。

当 CTest 被要求只执行一部分测试时(例如,通过使用正则表达式或使用 --rerun-failed 命令行选项运行时),它将自动添加任何由执行集中的任何测试所需的 fixture 的设置或清理测试。可以通过 ctest(1)-FS-FC-FA 命令行选项来覆盖此行为(如果需要)。

由于设置和清理任务也是测试,因此它们可以像其他任何测试一样,通过 DEPENDS 测试属性指定其顺序。这可以用来实现使用多个测试来处理单个 fixture 的设置或清理,从而使设置或清理逻辑模块化。

Fixture 的概念与 RESOURCE_LOCK 指定的资源的概念不同,但它们可以一起使用。Fixture 定义了一组共享设置和清理要求的测试,而资源锁的作用是确保特定测试集不会并行运行。某些情况可能需要两者兼顾,例如设置数据库,串行化对该数据库的测试访问,并在最后删除数据库。对于这种情况,测试将同时填充 FIXTURES_REQUIREDRESOURCE_LOCK 来结合这两种行为。用于 RESOURCE_LOCK 的名称与 fixture 的名称无关,因此请注意,资源锁不表示 fixture,反之亦然。

请考虑以下示例,该示例代表了上面提到的类似数据库测试场景

add_test(NAME testsDone   COMMAND emailResults)
add_test(NAME fooOnly     COMMAND testFoo)
add_test(NAME dbOnly      COMMAND testDb)
add_test(NAME dbWithFoo   COMMAND testDbWithFoo)
add_test(NAME createDB    COMMAND initDB)
add_test(NAME setupUsers  COMMAND userCreation)
add_test(NAME cleanupDB   COMMAND deleteDB)
add_test(NAME cleanupFoo  COMMAND removeFoos)

set_tests_properties(setupUsers PROPERTIES DEPENDS createDB)

set_tests_properties(createDB   PROPERTIES FIXTURES_SETUP    DB)
set_tests_properties(setupUsers PROPERTIES FIXTURES_SETUP    DB)
set_tests_properties(cleanupDB  PROPERTIES FIXTURES_CLEANUP  DB)
set_tests_properties(cleanupFoo PROPERTIES FIXTURES_CLEANUP  Foo)
set_tests_properties(testsDone  PROPERTIES FIXTURES_CLEANUP  "DB;Foo")

set_tests_properties(fooOnly    PROPERTIES FIXTURES_REQUIRED Foo)
set_tests_properties(dbOnly     PROPERTIES FIXTURES_REQUIRED DB)
set_tests_properties(dbWithFoo  PROPERTIES FIXTURES_REQUIRED "DB;Foo")

set_tests_properties(dbOnly dbWithFoo createDB setupUsers cleanupDB
                     PROPERTIES RESOURCE_LOCK DbAccess)

此示例的关键点

  • 定义了两个 fixture:DBFoo。测试可以像 fooOnlydbOnly 那样要求单个 fixture,或者它们可以像 dbWithFoo 那样依赖于多个 fixture。

  • 设置了一个 DEPENDS 关系,以确保 setupUserscreateDB 之后执行,这两者都是 DB fixture 的设置测试,因此将自动在 dbOnlydbWithFoo 测试之前执行。

  • 没有明确的 DEPENDS 关系来使设置测试在常规测试之前运行或清理测试在常规测试之后运行。

  • Foo fixture 没有定义设置测试,只有一个清理测试。

  • testsDoneDBFoo 两个 fixture 的清理测试。因此,它将在两个 fixture 的常规测试完成后(即在 fooOnlydbOnlydbWithFoo 之后)执行一次。没有为 testsDone 指定 DEPENDS 关系,因此它可以自由地与任一 fixture 的其他清理测试并行运行、在它们之前或之后运行。

  • 设置和清理测试从不列出它们所属的 fixture 在其自身的 FIXTURES_REQUIRED 属性中,因为这会导致对自身的依赖,并被视为错误。