Visual Studio 2010: Building and development cycle with Google Test? - c++

Using Visual Studio 2010 C++ with googletest. I'm new to unit testing and I've created a test solution to experiment with it. I have three projects in the solution:
HelloService (static lib)
HelloService.Tests (exe, a console app I think, linked with gmock_main.lib)
HelloApp (MFC exe, my main app)
I've got googletest (and googlemock) compiled linked and successfully working. My question is with the code test development cycle. I'm trying to understand the proper workflow with testing. Currently if I set HelloService.Tests as the "StartUp project" then when I hit F5 the tests run, but my HelloApp doesn't. If I set my HelloApp as the startup project then when I hit F5 my app runs but my tests don't.
I would think that I would want my "HelloApp" as the startup project but my tests to run when I build it and before I run it. Is that right? How do I set it up to do that?

The solution for me was to set the HelloApp as the StartUp project and then right click on the HelloApp project and choose "Project Dependencies..." and then check the HelloService.Tests project (the HelloService project was already checked). Now when I hit F5 the test project gets run (because HelloService.Tests already had a post-build event on it to run itself)
My only concern is if creating a project dependency creates some kind of code dependency. My guess is it doesn't but I'd like to know for sure.

You can set a post-build event on your tests project to run the test executable. Then, adding the test project as a dependency of the main app will run the tests automatically with each build. This does mean that the build will fail if any tests fail. It's up to you to decide whether to still run the app or fix the failing tests first.

Related

Can VS Code Test Explorer Catch2 extension automatically outdate tests when sources change

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)?

Having a solution that contains MFC project and console application for unit testing

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.

nunit-agent seems to be failing to load probing privatePath from tests configuration

Previously, when I had only Visual Studio 2010, my unit tests were executing fine.
Basically, my tests are composed of two files: UnitTests.dll and UnitTests.dll.config. Where UniTests.dll.config had a custom probing privatePath (e.g., Public;Extensions;Lib)
In order to execute, I used to follow this workflow:
1. I copied both files (i.e. UnitTests.dll and .config) to the folder were my application under test is located.
2. Open NUnit gui.
3. Execute the tests with ShadowCopy disabled, because my tests need to load the dlls from my application under test.
This was working fine!
After I installed Visual Studio 2012, the tests were not running anymore. And later, I figured out a workaround, but it is something that I don't want to use in my solution.
Now, I have to follow this workflow to make the tests running:
I copy both files (i.e. UnitTests.dll and .config) to the folder where my application under test is located.
I copy all the NUnit installation files (i.e. nunit-agent, nunit-console, etc.) to the folder where my application under test is located.
I change the probing privatePath from nunit-agent.dll.config in order to include the same paths from my UnitTests.dll.config.
Open NUnit gui which is located in my application under test folder.
Execute the tests with ShadowCopy disabled.
Note that I had to include steps 2 and 3 in order to run my unit tests. Somehow, I think nunit-agent.dll is not loading the probing privatePath from the config file of my test assembly.
Does anyone know why this is happening? Does anyone have a workaround where I don't need to change the nunit-agent.dll.config and copy the nunit installation files?
Thanks in advance.

Debugging native/managed C++ in VS 2010 with NUnit

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.

VC++ project never up-to-date

I'm using Visual Studio 2008.
I have a solution with two projects. One builds a DLL, which is my "production code". The other builds a console app exe, which is my unit test suite.
For my unit test project, I have listed as linker inputs the names of the source modules from the DLL. I.e., I have a DLLMain.cpp in the DLL project, and a linker input "DLLMain" in the exe project. This allows the exe to link with the obj files produced by the DLL project, preventing recompilation of those modules just for the unit tests. (Saves a lot of build time.)
THE PROBLEM IS that because the exe is produced later than the obj's, and by a different project, its timestamp is always newer than the obj's. So when you try to run or debug, it ALWAYS says the exe project is out of date and needs to be rebuilt.
Is there some way I can configure the exe project to ignore the timestamps? Or is there some other, perhaps more general, solution I'm not seeing here?
Seems like you are creating foo.obj in the DLL's project, linking foo.obj in the DLL project to produce the DLL, and then linking foo.obj to your EXE project without first recompiling it.
I have never done this before, but first thing I would check is to make sure the Intermediate Directory settings are the same for both the EXE project and the DLL project.
Go to the project that is not needed for unit testing
Right click on it and press Properties
Click on Configuration manager
Add a new configuration using the first drop down list
Click ok
Select that configuration in the window that is now focused
then in configuration properties set "Excluded From Build" to yes