# vs test explorer and gtest\_discover\_test working directory
**URL:** https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296
**Category:** Usage
**Tags:** gen:vs
**Created:** [July 21, 2024, 9:02am UTC](https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296 "2024-07-21T09:02:09Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@gbug](https://discourse.cmake.org/u/gbug)
#### Post date: [July 21, 2024, 9:02am UTC](https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296/1 "2024-07-21T09:02:09Z")
Hi! I have a strange issue with `gtest_discovery_tests` and custom working directory with VS Test Explorer – on some machines the working directory is set as expected and on some it doesn’t.
In my project I have a `tests` directory with subdirectories for each unit test suite:
```auto
CMakeLists.txt
|-- tests/
|-- CMakeLists.txt
|-- data/
| | -- CMakeLists.txt
|-- unit1/
|-- CMakeLists.txt
...
```
Root CMakeLists.txt contains `enable_testing()` and `add_subdirectory(tests)`. In the tests/CMakeLists.txt I reset runtime output directory to the current binary dir: `set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})`.
Each unit’s CMakeLists.txt contains `gtest_discover_tests(tst_unit WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY})`
There is also a `data` project which contains some external files for unit tests. Its CMakeLists.txt just copies them into runtime directory:
`file(COPY "${CMAKE_CURRENT_SOURCE_DIR}/data/" DESTINATION "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/data")`.
The problem is that for several of my colleagues the working directory seems not set and the default one is used when run the tests from VS Test Explorer. And running the tests using `ctest` command works for them. The test files are copied to the correct directory while test executables are placed in their own subdirectories instead of the common one I set in the tests/CMakeLists.txt
I’m stuck as on my machine everything works. Did I misconfigure or forget to set something? Maybe it’s not a good idea to reset `CMAKE_*_DIRECTORY` variables and better to use custom ones? Or it’s not cmake issue at all and I should ask VS guys?
cmake 3.30.0, windows 11, vs 2020 17.10.4
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [July 21, 2024, 10:23pm UTC](https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296/2 "2024-07-21T22:23:39Z")
My first thought is to check the directory you’re trying to set `WORKING_DIRECTORY` to. For the machines that fail, does that path contain any spaces or other special characters? It’s possible that the way the path is copied to some scripts is not handling those correctly, but let’s see if there’s some common characteristic to the paths that are failing compared to those that don’t.
---
### Author:  [@gbug](https://discourse.cmake.org/u/gbug)
#### Post date: [July 22, 2024, 8:57am UTC](https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296/3 "2024-07-22T08:57:46Z")
I haven’t noticed any special characters in the paths.
[CMakeCache.2.txt](https://discourse.cmake.org/uploads/short-url/A0pLfSjJ5Sd96Ayn6QBKhGNMPxM.txt) (44.7 KB)
[CMakeCache.txt](https://discourse.cmake.org/uploads/short-url/lt3kI5wt1Za6GVnHLDIb6kU2ii3.txt) (52.9 KB)
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [July 22, 2024, 9:41pm UTC](https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296/4 "2024-07-22T21:41:57Z")
Strange indeed. I don’t know how Visual Studio’s Test Explorer runs the tests, but it seems suspicious that your users only see problems when running tests through that. If it is working from the command line, that makes me think there’s something unusual in how it is doing that. I can’t offer any further advice on this one except maybe post a bug report in their issue tracker and see if they give you any response. The fact that running `ctest` directly works for all your users makes it less likely to be a bug in CMake/ctest.
Maybe also check what Visual Studio version people are running and see if there is a correlation between the version and the machines where it fails.
---
### Author:  [@gbug](https://discourse.cmake.org/u/gbug)
#### Post date: [July 23, 2024, 6:13am UTC](https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296/5 "2024-07-23T06:13:54Z")
Thanks for the reply, Craig! I suspected it’s a VS issue, but just wanted to be sure my approach with cmake is generally correct. I’ll ask VS guys and update this topic if a solution is found.
---
### Author:  [@MBAN](https://discourse.cmake.org/u/MBAN)
#### Post date: [July 24, 2024, 8:40pm UTC](https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296/6 "2024-07-24T20:40:21Z")
I had the same issue, but couldn’t get it to work.
I ended up changing our tests to be able to run in the target directory.
They needed access to some rather large data files that were to cumbersome to copy to the target directory each time, so I had CMake generate a file with paths to the data files next to the test executable. The tests read this file to find the location of the data files.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [July 24, 2024, 9:29pm UTC](https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296/7 "2024-07-24T21:29:20Z")
Another thing to check is what `ctest` Visual Studio uses when it runs tests. In the past, Microsoft have bundled their own non-official CMake as part of the VS install. If you can track down what `ctest` they are using, it would be worthwhile trying to run that particular binary from the command line to see if you can reproduce your problem that way. If you can, that would point to a change they made rather than a bug in CMake itself.
---
### Author:  [@gbug](https://discourse.cmake.org/u/gbug)
#### Post date: [August 7, 2024, 5:20pm UTC](https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296/8 "2024-08-07T17:20:09Z")
It seems that the problem was with `data` library, it’s header-only and VS puts it under `/tests` while the rest units under `/tests/`. One way to workaround this is to make `data` a normal library thus it will be placed together with the rest tests. But it doesn’t explain why the original approach works on some machines and not on the others.
I gave up to investigate this and started to use the absolute names for the external files in `data` library. In the `data/CMakeLists.txt` I added:
```auto
set(DATA_DIR "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/data")
target_compile_definitions(data INTERFACE DATA_DIRECTORY=${DATA_DIR})
```
and in `data/data.h` I added:
```auto
#define TEST_STRINGIFY(x) #x
#define TEST_STRINGIFY_DEFINE(x) TEST_STRINGIFY(x)
static inline const std::string current_test_dir = TEST_STRINGIFY_DEFINE(DATA_DIRECTORY);
```
// My colleagues and me used both, VS’ cmake and the standalone one, the results were the same – works for me, doesn’t work for them.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [August 7, 2024, 10:44pm UTC](https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296/9 "2024-08-07T22:44:45Z")
Do you and your colleagues have the same Visual Studio version installed?
---
### Author:  [@gbug](https://discourse.cmake.org/u/gbug)
#### Post date: [August 8, 2024, 4:48am UTC](https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296/10 "2024-08-08T04:48:13Z")
No, one of them has vs19 while the rest have vs22
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [August 9, 2024, 12:16am UTC](https://discourse.cmake.org/t/vs-test-explorer-and-gtest-discover-test-working-directory/11296/11 "2024-08-09T00:16:02Z")
You need to look at the full version, not just v19 or v22. Check what update/patch release is installed. It is not unusual for a problem to exist in one update and be fixed in another within a major release series.