- This topic has 3 replies, 2 voices, and was last updated 3 years, 11 months ago by
.
-
Posts
-
Hello,
I am trying to integrate a VisualGDB embedded cmake project with simulated unit tests into our TFS pipeline. After some initial problems the project now builds successfully and the unit tests are executed. However publishing the generated TRX file fails with the error message “The added or subtracted value results in an un-representable DateTime.”
After a quick look in the TRX file (attached) it is obvious that the date is formatted with the local culture (14.12.2020 17:50:20) and therefore differs a lot from the format used by e.g. vstest.console.exe (2020-12-15T08:18:09.0000000+01:00). I assume this is the reason why the publish fails. Could you please have a look into it?Maybe you are also interested in the other pitfalls I mentioned earlier:
Installing packages from the command line with VisualGDB.exe /pkgmgr does not generate all files in %AppData%\Local\VisualGDB (e.g. FindBSP.cmake was missing). As soon as I opened “Manage VisualGDB packages” inside Visual Studio the missing files where generated immediately, even without changing anything.
The second problem was not so obvious: The test discovery from the command line either with /listtests or /runtests does not work if all test executables are defined in a subdirectory included with add_subdirectory. As soon as a test executable is defined in the main CMakeLists.txt the discovery works also for the definitions in the subdirectories. It is even possible to guard the definition with “if(SHOULD_NEVER_BE_ENTERED) … endif()” to hide the extra test executable inside Visual Studio.Thanks!
Hi,
No problem. Please try this build: VisualGDB-5.5.104.3927.msi
It uses invariant culture for formatting of timestamps in the .trx files and also updates the BSP files after running VisualGDB.exe /pkgmgr. If the problem with the .trx files persists, please try editing a faulty file manually until it is accepted by your source control system, and then attach both files in a .zip archive (sorry, due to the limitations of our forum engine, it requires a whitelist of supported attachment extensions).
We have tried reproducing the problem with tests in subdirectories, however it worked as expected. Can you confirm that you are specifying the correct .vgdbtestcontainer file when running VisualGDB.exe /listtests? The container file should explicitly mention the target in the Target element. Also if you could create a very basic project, archive it to a zip file (including the .vgdbtestcontainer file) and attach it here along with the exact repro command line and output from VisualGDB.exe, we should be able to fix it promptly.
Hi,
thanks, the build solves the problem with publishing the unit tests results and they are now showing up inside TFS.
I was following the Creating Simulation Platforms to Test Embedded Code without Hardware tutorial which recommends to run /listtests using .<span class=”crayon-i”>vgdbcmake. I have attached a sample project with the issue including the used command line and output. The only difference between “listtests fail.txt” and “listtests success.txt” is that add_bsp_based_executable(…) in CMakeLists.txt was commented out.</span>
Thanks!
No worries and thanks very much for the detailed repro instructions.
The problem happened because the part of VisualGDB that determines whether a project contains unit tests without fully loading it (i.e. without opening it in VS or using test containers produced by VS) only scans the main CMakeLists.txt file.
We have updated it to only check the find_test_framework() statement, although it still needs to be present in the main CMakeLists.txt file. Please try this build: VisualGDB-5.5.104.3931.msi
If you want to support a more complex project structure, please consider using the test container files instead. These files (*.vgdbtestcontainer) are generated by VisualGDB when using the Visual Studio’s test explorer, and contain detailed snapshots of various target properties reported by CMake. You can pass a .vgdbtestcontainer file to VisualGDB.exe instead of the .vgdbcmake file, so that VisualGDB won’t need to reconstruct anything by parsing the CMakeLists.txt files. Test container files include the target path, so no /targetpath switch is needed when using them.
- You must be logged in to reply to this topic.