# Ensure binary is created before add\_test is run
**URL:** https://discourse.cmake.org/t/ensure-binary-is-created-before-add-test-is-run/6042
**Category:** Code
**Created:** [July 10, 2022, 6:30pm UTC](https://discourse.cmake.org/t/ensure-binary-is-created-before-add-test-is-run/6042 "2022-07-10T18:30:22Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Anuj\_Choudhury](https://discourse.cmake.org/u/Anuj_Choudhury)
#### Post date: [July 10, 2022, 6:30pm UTC](https://discourse.cmake.org/t/ensure-binary-is-created-before-add-test-is-run/6042/1 "2022-07-10T18:30:22Z")
I am trying to run individual tests for Boost in CMake.
a Boost test binary can be run with [`--list_content` option](https://www.boost.org/doc/libs/1_63_0/libs/test/doc/html/boost_test/utf_reference/rt_param_reference/list_content.html) to list down all the tests inside the executable.
I am using this list with CMake’s add\_test option to add individual tests. However, the problem is when I build all(ie run the root CMake script), it tries to run add\_test before the Boost test binary is even compiled, due to which the above `--list_content` command fails, and no tests get added to ctest. For eg:
```auto
add_executable(end_to_end_test tests/end_to_end_test.cpp)
target_link_libraries(end_to_end_test Dep1 Dep2 )
add_boost_test_fn(end_to_end_test) # this function runs the above end_to_end_test binary with --list_content option and adds individual tests
```
Here, add\_boost\_test\_fn(which runs add\_test internally) seems to be running before end\_to\_end\_test executable is even generated.
By contrast, if this binary already exists, and then the root CMake script is run, these tests get added fine.
How can it be ensured that `add_test` is run for a binary only after the binary is compiled and generated in its correct location ?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [July 10, 2022, 6:59pm UTC](https://discourse.cmake.org/t/ensure-binary-is-created-before-add-test-is-run/6042/2 "2022-07-10T18:59:28Z")
It sounds like something like the GTest mechanism should be implemented for Boost.Test. This defers listing the tests until `ctest` time (AFAIK).
Cc: @Matthew_Woehlke @pdimov
---
### Author:  [@Anuj\_Choudhury](https://discourse.cmake.org/u/Anuj_Choudhury)
#### Post date: [July 10, 2022, 9:01pm UTC](https://discourse.cmake.org/t/ensure-binary-is-created-before-add-test-is-run/6042/3 "2022-07-10T21:01:46Z")
Hi, what is the GTest mechanism ?
I want a prerequisite, or a dependency for the add\_boost\_test\_fn function, so that I can say that the function (which internally runs the above binary in execute\_process command) is run after the test binary is built first.
---
### Author:  [@Anuj\_Choudhury](https://discourse.cmake.org/u/Anuj_Choudhury)
#### Post date: [July 10, 2022, 9:18pm UTC](https://discourse.cmake.org/t/ensure-binary-is-created-before-add-test-is-run/6042/4 "2022-07-10T21:18:23Z")
I see there’s also a problem with [execute\_process](https://cmake.org/cmake/help/latest/command/execute_process.html), since it runs prior to system generation. I need to run add\_custom\_target/command for the above purpose instead…
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [July 11, 2022, 10:33am UTC](https://discourse.cmake.org/t/ensure-binary-is-created-before-add-test-is-run/6042/5 "2022-07-11T10:33:55Z")
Correct. Prior to `add_test` is impossible (because it happens during configure). I believe the GTest mechanism is to defer test detection until test time so that the tests are discovered at that point. But those that I Cc’d probably know better.
---
### Author:  [@Matthew\_Woehlke](https://discourse.cmake.org/u/Matthew_Woehlke)
#### Post date: [July 11, 2022, 5:16pm UTC](https://discourse.cmake.org/t/ensure-binary-is-created-before-add-test-is-run/6042/6 "2022-07-11T17:16:49Z")
I would recommend reading through `GoogleTest.cmake`. There are actually two modes; build-time discovery (more efficient; only needs to run if the test changes) and test-time discovery (tends to work better if the test needs environmental setup, e.g. especially on cross-compiles). The general idea, however, is that something post-configure generates the `add_test` commands into something that is invoked by a script that is added to [`TEST_INCLUDE_FILES`](https://cmake.org/cmake/help/latest/prop_dir/TEST_INCLUDE_FILES.html). (The additional level of indirection is so the ‘first’ script, which is guaranteed to exist, can check if the test executable or generated test list exists and produce more useful diagnostics in case of a failure.) The wrapper ([`gtest_discover_tests`](https://cmake.org/cmake/help/latest/module/GoogleTest.html#command:gtest_discover_tests)) handles setting all this up; users never call `add_test` directly.
In fact, I would recommend _copying_ from `GoogleTest.cmake` as much as possible, as there is a bunch of corner-case handling that you probably don’t want to have to reinvent or rediscover.