FIXTURES_REQUIRED.rst 4.6 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394
  1. FIXTURES_REQUIRED
  2. -----------------
  3. Specifies a list of fixtures the test requires. Fixture names are case
  4. sensitive.
  5. Fixtures are a way to attach setup and cleanup tasks to a set of tests. If a
  6. test requires a given fixture, then all tests marked as setup tasks for that
  7. fixture will be executed first (once for the whole set of tests, not once per
  8. test requiring the fixture). After all tests requiring a particular fixture
  9. have completed, CTest will ensure all tests marked as cleanup tasks for that
  10. fixture are then executed. Tests are marked as setup tasks with the
  11. :prop_test:`FIXTURES_SETUP` property and as cleanup tasks with the
  12. :prop_test:`FIXTURES_CLEANUP` property. If any of a fixture's setup tests fail,
  13. all tests listing that fixture in their ``FIXTURES_REQUIRED`` property will not
  14. be executed. The cleanup tests for the fixture will always be executed, even if
  15. some setup tests fail.
  16. When CTest is asked to execute only a subset of tests (e.g. by the use of
  17. regular expressions or when run with the ``--rerun-failed`` command line
  18. option), it will automatically add any setup or cleanup tests for fixtures
  19. required by any of the tests that are in the execution set.
  20. Since setup and cleanup tasks are also tests, they can have an ordering
  21. specified by the :prop_test:`DEPENDS` test property just like any other tests.
  22. This can be exploited to implement setup or cleanup using multiple tests for a
  23. single fixture to modularise setup or cleanup logic.
  24. The concept of a fixture is different to that of a resource specified by
  25. :prop_test:`RESOURCE_LOCK`, but they may be used together. A fixture defines a
  26. set of tests which share setup and cleanup requirements, whereas a resource
  27. lock has the effect of ensuring a particular set of tests do not run in
  28. parallel. Some situations may need both, such as setting up a database,
  29. serialising test access to that database and deleting the database again at the
  30. end. For such cases, tests would populate both ``FIXTURES_REQUIRED`` and
  31. :prop_test:`RESOURCE_LOCK` to combine the two behaviours. Names used for
  32. :prop_test:`RESOURCE_LOCK` have no relationship with names of fixtures, so note
  33. that a resource lock does not imply a fixture and vice versa.
  34. Consider the following example which represents a database test scenario
  35. similar to that mentioned above:
  36. .. code-block:: cmake
  37. add_test(NAME testsDone COMMAND emailResults)
  38. add_test(NAME fooOnly COMMAND testFoo)
  39. add_test(NAME dbOnly COMMAND testDb)
  40. add_test(NAME dbWithFoo COMMAND testDbWithFoo)
  41. add_test(NAME createDB COMMAND initDB)
  42. add_test(NAME setupUsers COMMAND userCreation)
  43. add_test(NAME cleanupDB COMMAND deleteDB)
  44. add_test(NAME cleanupFoo COMMAND removeFoos)
  45. set_tests_properties(setupUsers PROPERTIES DEPENDS createDB)
  46. set_tests_properties(createDB PROPERTIES FIXTURES_SETUP DB)
  47. set_tests_properties(setupUsers PROPERTIES FIXTURES_SETUP DB)
  48. set_tests_properties(cleanupDB PROPERTIES FIXTURES_CLEANUP DB)
  49. set_tests_properties(cleanupFoo PROPERTIES FIXTURES_CLEANUP Foo)
  50. set_tests_properties(testsDone PROPERTIES FIXTURES_CLEANUP "DB;Foo")
  51. set_tests_properties(fooOnly PROPERTIES FIXTURES_REQUIRED Foo)
  52. set_tests_properties(dbOnly PROPERTIES FIXTURES_REQUIRED DB)
  53. set_tests_properties(dbWithFoo PROPERTIES FIXTURES_REQUIRED "DB;Foo")
  54. set_tests_properties(dbOnly dbWithFoo createDB setupUsers cleanupDB
  55. PROPERTIES RESOURCE_LOCK DbAccess)
  56. Key points from this example:
  57. - Two fixtures are defined: ``DB`` and ``Foo``. Tests can require a single
  58. fixture as ``fooOnly`` and ``dbOnly`` do, or they can depend on multiple
  59. fixtures like ``dbWithFoo`` does.
  60. - A ``DEPENDS`` relationship is set up to ensure ``setupUsers`` happens after
  61. ``createDB``, both of which are setup tests for the ``DB`` fixture and will
  62. therefore be executed before the ``dbOnly`` and ``dbWithFoo`` tests
  63. automatically.
  64. - No explicit ``DEPENDS`` relationships were needed to make the setup tests run
  65. before or the cleanup tests run after the regular tests.
  66. - The ``Foo`` fixture has no setup tests defined, only a single cleanup test.
  67. - ``testsDone`` is a cleanup test for both the ``DB`` and ``Foo`` fixtures.
  68. Therefore, it will only execute once regular tests for both fixtures have
  69. finished (i.e. after ``fooOnly``, ``dbOnly`` and ``dbWithFoo``). No
  70. ``DEPENDS`` relationship was specified for ``testsDone``, so it is free to
  71. run before, after or concurrently with other cleanup tests for either
  72. fixture.
  73. - The setup and cleanup tests never list the fixtures they are for in their own
  74. ``FIXTURES_REQUIRED`` property, as that would result in a dependency on
  75. themselves and be considered an error.