I have visual studio solution. It contains 4 projects.
Main project (tested project), built as .lib
Wrapper project that contains just main and runs Main project, built as .exe
Google Test project which builds google test library, buit as .lib
UnitTest project that uses 3. and 1., built as .exe
I am using GoogleTestAdapter so my unit test from project 4. are available through visual studio's test explorer and I can test my project just fine.
The problem is that when i run code coverage using Microsoft's code coverage tool I am not getting any coverage results for my Main project. I can only see code coverage for Google Test project (3.) which is weird since both Main project and Google Test project are set up the same way.
Classes from my Main project are not present in code coverage report. I can only see them there if I actually write some tests for that classes and even then code coverage for that classes is 0%.
Related
I'm using VS Code Test Explorer with python extension on a project. It is awesome. If I change any source files, the relevant tests in Test explorer will be highlighted as out of date so I know I have to run them again to check everything is ok.
I'm trying to do the same thing with a C/C++ project and the Test Explorer Catch2 extension. I have a simple meson project file to build my test executable(s).
It works well in that my tests are discovered and I can run them, HOWEVER if I change a source file it the tests wont show as out of date to indicate that they need to be rerun.
I know this is a dependency issue with meson (or what ever build system that VS Code understands).
Is there a Test Explorer (or VS Code) way of for determining which exes are out of date and need building (tests and build in general)?
I have a solution which containes serveral projects (An MFC Application and the others are DLL projects). Is it possible to add another console application project (BOOST TEST) to unit test a specific DLL project, without modifying anything in the production MFC application and succeeding in building the whole solution?
I want only the test console application to run as a post build and then launching the prodution MFC application.
I wrote a series of blog posts on test-driven development in C++ that show you step-by-step how to do TDD in C++ with Visual Studio and Boost.Test. The steps would be nearly identical for your situation with the exception that your console test project depends on the DLL project instead of the static library project that I used in my article.
If I understand you correctly you want the build of the solution to compile and run the tests. If you say "build and run in the debugger" (F5), you want to compile all the code, run the tests and then run the application if the tests pass. This is not hard to do.
Set up the console unit test program as outlined in my blog posts and that will make the unit test project compile and run as part of the build. So if you say "build and run in the debugger" (F5) in Visual Studio, it will build the solution and then run the startup project, e.g. your MFC application. Since the solution contains the unit test console executable project, it will build that project. The unit test project has the post-build step to execute the tests, so the tests will run as part of the build.
Because your unit test executable depends on a DLL, you will need to make sure the DLL is found by the executable at run-time. You may need to add additional commands to your post-build step to copy the DLL to the necessary directory before running the test executable. You can verify this works properly by setting your unit test project as the startup project and running it in the debugger.
Double check in the configuration manager that all the projects are set to build for your combination of platform and configuration. Sometimes if you have customized these in your solution when you add a new project it isn't automatically checked to compile in the custom platform/configuration combination.
If this isn't working for you, then add a comment or edit your question to include more specifics about what isn't working.
I have DLL plug-in, which I'd like to test and launch on TeamCity: it contains .h and .cpp files
What is the right strategy to test this DLL:
Create a new Test Project in the same solution, configure 'include directory' to see sources and copy DLL project files to Test console project. In this case I have the same solution but in console mode, which I can test in normal way. But if my DLL project will change I need to synchronize source files.
Create export function in my DLL, like 'runTests()' which will produce XML file with results. TeamCity will process this? And how should it run this? And some stuff function appears in release DLL...
To unit test our libraries, we create standalone unit testing console executables. so:
For each library , we create a console executable testing each method in the API.
Each source file is obviously added to a SCM so modifying files will automatically be reflected into the unit testing program;
All this (source updates, compilation, unit testing and doc generation) is added to our CI server (Jenkins) so that all libraries, for all unit testing programs are always recompiled from scratch;
The documentation for the library API is constructed with Doxygen using snippet from this program. This has a nice side-effect: changing the API will break your unit tests. So you have to fix your unit tests so your documentation is always up to date.
I'm developing a C++ project in Visual Studio 2012 that uses driver code to interface with an open DMX box(ENTTEC DMX USB PRO). Thus far, I've been writing code and compiling as an EXE so I could use main() to run unit tests.
I want to port this over so that I have the device interface code that compiles down to a .DLL, then a separate source file that contains C++ code to compile an EXE that links to the DLL and makes calls to the functions to run the tests.
Essentially, when I go to debug, is there a way to setup Visual Studio 2012 to generate a .DLL and an .exe making calls to the .DLL and run the .exe automatically all in one step? I'm new to Visual Studio and find it quite confusing.
Yes. Setup two projects in your solution: One for your main code (generating a DLL) and one for your executable, where your unit tests reside. Then look under project dependencies (under the Project menu on VS2010, not sure about 2012) to make the EXE dependent on the DLL (that will make sure the EXE rebuilds/relinks when necessary).
Right-click on the EXE project in the Solution Explorer and select Properties. There you can setup the includes/linker to get to your header/lib file, if necessary (it might not be necessary if you use LoadLibrary explicitly or something, but I'm guessing you're not doing that).
Now in the project settings for the EXE under build events, add a post-build event that runs your tests. Note that if your EXE returns something other than 0 from main(), VS can report that as an error in the build.
Is there a way to set breakpoints and step through them using NUnit with a mixed project of native C++ and managed C++?
I have my SUT (Software Under Test) configured as a static library (native C++)
I have my unit test suite as a separate project configured as a dll that depends on my previously stated library. I also added said library as a reference to my unit test project.
My tests run fine in NUnit, breakpoints just don't work.
Again, is there a way to get the breakpoints to work with NUnit with Native/Managed C++?
The most convenient way to do this is to set up a custom tool entry specifying the path to NUnit as the command. For a VS2003 C# project, you can use $(TargetPath) for the arguments and $(TargetDir) for the initial directory.
With Visual Studio VS2005 this becomes a bit harder, because that release changed the meaning of the 'Target' macros so they now point to the intermediate 'obj' directories rather than the final output in one of the 'bin' directories. Here are some alternatives that work in both versions:
$(ProjectDir)$(ProjectFileName) to open the VS Project rather than the assembly. If you use this approach, be sure to rename your config file accordingly and put it in the same directory as the VS project file.
$(ProjectDir)bin/Debug/$(TargetName)$(TargetExt) to run the assembly directly. Note that this requires hard-coding part of the path, including the configuration.
If you would like to debug your tests, use the Visual Studio Debug | Processes… menu item to attach to NUnit after starting it and set breakpoints in your test code as desired before running the tests.