Open SunBlack opened 5 years ago
Another thing: Imho test files should not be passed as parameter, because mostly a test case is for a specific test file, so test file should be fix. So test file should be loaded relative to working directory.
:+1: In my projects I typically write CMake script that computes test data location path and then passes it as a compiler definition when building tests.
We are copying data, so we have no fixed path in executable
add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_SOURCE_DIR}/data $<TARGET_FILE_DIR:${PROJECT_NAME}>/testdata/mylib)
Not sure I understand you. The test data is inside our repository, why can't we incorporate paths to these files into the test binaries? Even if you copy test data elsewhere afterwards, how does it matter for the unit tests?
Example from our project: Sometimes I copy build artifact from our build server to another server. If it is a new server I copy test executable, too, so I can check if all dependencies (dynamic linkes libraries, required other data, ...) are correct in place.
Pro of copying data: No fixed path Cons of copying data: Duplication of test files. Don't know how big all test files accumulated in PCL are, but as far as I can see (~50MB in pcl/test) there are no big testfiles, so it is no real issue.
An alternative to both variants: a environment variable containing path to test data. Imho better than fixed paths, but still ugly compared to relative paths.
+1 In my projects I typically write CMake script that computes test data location path and then passes it as a compiler definition when building tests.
I'm ok in going with this, (passing relative paths. relative paths can rendered useless in some out of tree builds as pointed out below.)
Relative to what exactly? Please note that sometimes build/
directory is placed completely outside of the source tree. (For example, on a different partition where an SSD drive is mounted.)
Marking this as stale due to 30 days of inactivity. It will be closed in 7 days if no further activity occurs.
I started to use VS 2017 + PCL project with environment variables, so I can start apps, tests and all other stuff from IDE. But now I'm getting a lot of exception windows after opening PCL project. Output of tests window see end of this MR (because GitHub doesn't collapse it)
Example:
Reasons for this: VS2017 has an integrated GoogleTestAdapter (since 15.5, before it was an extension). This adapter tries to discover all tests by searching for executables containing
test
in name (with a regex, so a bit more complicated) and calling--gtest_list_tests
on found executables. But some/mosts executables are not handling this parameter correct, because they are expecting more parameters and are not able to even lists tests without this additional parametersE.g. take a look at https://github.com/PointCloudLibrary/pcl/blob/60f2b298b14c4e2eef31295d199fea066a80e420/test/features/test_rops_estimation.cpp#L121-L168
Following code should always be called, so parameters to GoogleTests are always handled
Fix: Use shared resources between tests in the same test case or use global set-up and tear-down (prefer first).
Another thing: Imho test files should not be passed as parameter, because mostly a test case is for a specific test file, so test file should be fix. So test file should be loaded relative to working directory.
Output of tests window: