# MSVS gtest\_discover\_tests environment
**URL:** https://discourse.cmake.org/t/msvs-gtest-discover-tests-environment/9225
**Category:** Usage
**Tags:** gen:vs
**Created:** [October 19, 2023, 11:01pm UTC](https://discourse.cmake.org/t/msvs-gtest-discover-tests-environment/9225 "2023-10-19T23:01:16Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@ivanschou](https://discourse.cmake.org/u/ivanschou)
#### Post date: [October 19, 2023, 11:01pm UTC](https://discourse.cmake.org/t/msvs-gtest-discover-tests-environment/9225/1 "2023-10-19T23:01:16Z")
I have a project that uses a third-party library and I’ve written unit tests and added them to my test suite via gtest\_discover\_tests, but in order to successfully build the test target in VS I need to add the path to the third-party DLL to the PATH environment variable before running the unit test executable.
I’ve tried to use ENVIRONMENT\_MODIFICATION to append to the PATH environment variable, but it doesn’t seem to do anything. I’ve tried to add a script to the TEST\_INCLUDE\_FILES to append to the PATH environment variable, and that doesn’t seem to do anything either. I can see the commands that in the POST\_BUILD event of the test target in my solution that invokes my unit test, but the target won’t successfully “build” in MSVS without some workaround. I have several workarounds, but they’re not ideal:
I could add the path to the third-party DLL to my system environment variables before running MSVS, but the idea is that I’m using CMake to find/specify the location of the third-party library so that my project is more “portable” to other members of my team. The way the third-party library is supplied or installed may differ for other those users. I’d prefer not to have to change my system environment just so that this test case can succeed.
I can manually edit the POST\_BUILD event command line and append to the PATH environment variable right after the “setlocal” command and right before the call to “cmake … -P GoogleTestAddTests.cmake” line after the MSVS solution is generated by CMake. The solution builds fine this way, but it’s annoying that CMake both knows where that third-party DLL is located (since it had to link to it), but I’m unable to inject the PATH line programmatically to the generated commands.
I can write a shell script that appends the path to the DLL to the PATH environment variable and invoke MSBUILD on the solution and everything works fine, but this solution is less friendly to other users who prefer to interact with the solution using the MSVS IDE.
Is there a better way to accomplish this?
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [October 20, 2023, 12:53am UTC](https://discourse.cmake.org/t/msvs-gtest-discover-tests-environment/9225/2 "2023-10-20T00:53:03Z")
It seems to me that `gtest_discover_tests` needs to learn about an `ENVIRONMENT` (or `ENVIRONMENT_MODIFICATION`) keyword argument to handle this case.
Cc: @Matthew_Woehlke
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [October 20, 2023, 9:39pm UTC](https://discourse.cmake.org/t/msvs-gtest-discover-tests-environment/9225/3 "2023-10-20T21:39:03Z")
I strongly recommend setting the `DISCOVERY_MODE` to `PRE_TEST`. You can add this directly to the `gtest_discover_tests()` call, or change the default globally by setting the `CMAKE_GTEST_DISCOVER_TESTS_DISCOVERY_MODE` variable to `PRE_TEST`. I generally recommend the latter, there are very few cases where you would prefer to be running the executable to get the list of tests at build time rather than test time, and there are also cases where you have no alternative but to do it at test time.
---
### Author:  [@ivanschou](https://discourse.cmake.org/u/ivanschou)
#### Post date: [October 23, 2023, 8:09pm UTC](https://discourse.cmake.org/t/msvs-gtest-discover-tests-environment/9225/4 "2023-10-23T20:09:52Z")
Thanks, that does help by basically eliminating the offending test when the third-party library isn’t in the search path. Ideally, it would be nice if the test could be made to work since CMake needs to know the location of the third-party DLL to successfully build the project so it would seem that path should somehow be able to be passed to the tests. Per Ben’s reply, is this because gtest\_discover\_tests doesn’t respect the ENVIRONMENT\_MODIFICATION property? I had added:
> PROPERTIES ENVIRONMENT\_MODIFICATION “PATH=path\_list\_append:/path/to/third-party/bin”
to my gtest\_discover\_tests call. I’m running cmake 3.27.3 and the GoogleTest documentation doesn’t specifically state that it supports ENVIRONMENT or ENVIRONMENT\_MODIFICATION, I assumed that because it allows setting test properties, that it did respect that property. That’s interesting.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [October 24, 2023, 1:03am UTC](https://discourse.cmake.org/t/msvs-gtest-discover-tests-environment/9225/5 "2023-10-24T01:03:17Z")
Note that the test discovery isn’t a test, so it doesn’t really have properties. The command would need to recognize and forward the requests as needed to the internal `execute_process` (that I suspect is) performed to extract the test list at build/test time.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [October 24, 2023, 3:24am UTC](https://discourse.cmake.org/t/msvs-gtest-discover-tests-environment/9225/6 "2023-10-24T03:24:51Z")
Your last comment reminded me this is a known issue after all. See the following issue: [https://gitlab.kitware.com/cmake/cmake/-/issues/21453](https://gitlab.kitware.com/cmake/cmake/-/issues/21453)
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [June 2, 2024, 11:56am UTC](https://discourse.cmake.org/t/msvs-gtest-discover-tests-environment/9225/7 "2024-06-02T11:56:15Z")
I added a [comment](https://gitlab.kitware.com/cmake/cmake/-/issues/21453#note_1530331) in that issue describing a way this can be handled now with CMake 3.29 or later. The `TEST_LAUNCHER` target property and its associated `CMAKE_TEST_LAUNCHER` variable can be used to get the desired result. Still not necessarily a clean as we might want, but it’s at least a workaround in the meantime while a more direct alternative can be discussed.