Sysprogs forums › Forums › VisualGDB › run gtest in tfs build with coverage
- This topic has 21 replies, 2 voices, and was last updated 5 years, 8 months ago by support.
-
AuthorPosts
-
February 6, 2019 at 21:26 #23735supportKeymaster
Thanks for the update. We have fixed the problem triggered with TFS in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2790.msi
The command line log looks like the coverage directories do not get stored in the test container file. Please double-check that you have enabled code coverage for both debug and release configurations in VisualGDB Project Properties. If this doesn’t help, please share your test container file here.
February 6, 2019 at 22:04 #23736dabramsonParticipantOK. Tfs can now run through gtests via the visualgdb command.
Setting code coverage for debug and release did not help the empty coverage issue. The scovreport generated for the tests running from the tfs agent is empty, as is the manual run from the command line.
I have a project under test (PUT) and the test project (TEST). I’m attaching screen shots of the settings for both PUT and TEST.
The test container is also attached as requested.
- This reply was modified 5 years, 9 months ago by dabramson.
Attachments:
You must be logged in to view attached files.February 8, 2019 at 07:32 #23768supportKeymasterThanks for clarifying that you have 2 projects. Most likely the problem is triggered by some combination of settings in those projects (we have previously tried to reproduce it with 1 project only), although it’s hard to pinpoint it from the current screenshots . The test container is missing the <CodeCoverage> element, so that explains why the code coverage it not handled, although this could be triggered by several different options.
Would you be able to reproduce the same problem on 2 freshly created projects, demonstrating the same settings (test frameworks, references between the projects), etc, and attach them here or send them via our support form? This should help us pinpoint and fix this without requesting any more details.
February 8, 2019 at 14:53 #23775dabramsonParticipantHello,
The project I’m working with is just a toy anyway to work out all of this coverage stuff before trying to apply it to a real project. I attached that project in whole. If it is important that the project I send you be from scratch please let me know and I’ll try to find time to do it.
Thanks
Attachments:
You must be logged in to view attached files.February 9, 2019 at 05:46 #23787supportKeymasterThanks for the project files. From a very brief look, it appears you main test project had code coverage disabled on the MSBuild level, so the test container generated by MSBuild (that is essentially a snapshot of MSBuild-level properties necessary for VisualGDB to launch the project outside MSBuild) did not have any coverage-related settings.
After we changed the setting (see below), the container appears OK.
We will run a few more tests on your solution and see if we can improve the usability for this scenario.
Attachments:
You must be logged in to view attached files.February 11, 2019 at 15:22 #23808dabramsonParticipantI turned that setting off because I wanted to NOT get coverage on the unit test project. I think that was the result of the suggestion in this post…
The only coverage I’m interested in is the tested code. Thank you for trying to make this better.
February 28, 2019 at 22:42 #24032supportKeymasterSorry for the delay. We have updated the VisualGDB logic for generating the test containers on the MSBuild level so that it includes the coverage information from referenced projects.
Please try this build: VisualGDB-5.4.103.2936.msi
Please ensure you enable the test container generation for ALL involved projects (the test project and the referenced libraries):
This will get the coverage to work correctly when running the tests from command line (ensure you use the correct test container with the <CodeCoverageInfo> elements when running tests via command line).
Attachments:
You must be logged in to view attached files. -
AuthorPosts
- You must be logged in to reply to this topic.