FIXTURES_REQUIRED

3.7 版本中新增。

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

Fixture 是一种将设置和清理任务附加到一组测试的方法。如果一个测试需要给定的 fixture,那么所有被标记为该 fixture 的设置任务的测试将首先被执行(对所有测试集执行一次,而不是对每个需要该 fixture 的测试执行一次)。在所有需要特定 fixture 的测试完成后,CTest 将确保该 fixture 的所有被标记为清理任务的测试随后被执行。测试通过 FIXTURES_SETUP 属性标记为设置任务,通过 FIXTURES_CLEANUP 属性标记为清理任务。如果 fixture 的任何设置测试失败,所有在其 FIXTURES_REQUIRED 属性中列出该 fixture 的测试将不会被执行。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 的其他清理测试之前、之后或并行运行。

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