![]() ![]() Since database setup has failed in that scenario, one would expect that dbTest1 and dbTest2 would not succeed, but the real problem would actually have been the setup, not whatever dbTest1 and dbTest2 were meant to be testing. Thus, in the above example, if the dbSetup test fails, the dbTest1 and dbTest2 tests will still run. ![]() The relationship says nothing at all about the success or failure of the tests, only the execution order. The DEPENDS test property only specifies that a particular test cannot run until after the tests it depends on have completed. There are, however, two main problems with this: Problem 1: Tests run even if setup fails When the full set of tests are executed by CTest, this arrangement would ensure that dbTest1 and dbTest2 would only run after dbSetup completed and dbCleanup would only run after both dbTest1 and dbTest2 completed. Set_tests_properties(dbCleanup PROPERTIES DEPENDS dbTest1 dbTest2) Set_tests_properties(dbTest1 dbTest2 PROPERTIES DEPENDS dbSetup) Explicit dependency relationships would then be defined between each individual test and the setup/cleanup tasks, which would look something like the following: add_test(NAME dbSetup COMMAND. Prior to CMake 3.7.0, the typical way this would be achieved is to define a new test for the setup task(s) and another for the cleanup task(s). Furthermore, when the test cases have all completed, they may have left behind a large amount of data which is no longer needed, or the accounts that were added may need to be removed again to prevent misuse or unbounded growth of new accounts. Some initial setup of that database may be required before the test cases can access it, such as creating accounts, setting permissions, loading initial data, etc. ![]() This article explains the new fixture features and provides examples showing how they complement the existing resource and dependency functionality.Ĭonsider the scenario where various test cases might interact with a database. On their own, fixtures are quite useful, but they also integrate well with the existing RESOURCE_LOCK and DEPENDS test properties to support some interesting use cases. Put simply, a fixture allows setup and cleanup tasks to be associated with a group of tests. If either of the test programs fail, the whole test fails.New test properties were added in CMake 3.7.0 to support test fixtures. The script will then execute your 2 programs in sequence. When you run make test or equivalent this will run "cmake -P runtests.cmake" setting the CMD1 and CMD2 variables to the appropriate test programs. $ gets expanded to the full path to the executable at build-file generation time. This script you can call runtests.cmake, it runs the commands CMD1 and CMD2 and checks each for a non-zero return code, returning out of CMake itself with an error if that happens: macro(EXEC_CHECK CMD)Įxecute_process(COMMAND $/runtests.cmake) But you can set variables to values, which is just as good. Sadly you can't pass arguments to such a script. CMake has the -P option for running arbitrary chunks of CMake scripting language when you run make or make test, rather than at Makefile generation time. To do this in a cross platform way, write the script in CMake itself. The add_test command only accepts one executable, but you can run any executable that is really a script. ![]()
0 Comments
Leave a Reply. |