No, sorry I've just been doing a lot of .NET stuff so I slipped into using that language again.
If you're only doing two projects how do you make a static library and executable out of one project (program) and a third executable? Visual studio's confusing me here.
EDIT: Oh, wait you're saying split up my program into two projects? That sounds like it could easily be a nightmare of a night.
I agree it can be dauting the first time you do it, but honestly it's not that hard. And you're going to have to do this no matter if you're using Visual Studio, Makefiles, CMake, or anything else. The reason is that your program and the unit test runner are two separate executables that need to share the same code -- the code that is being tested.
The way you share code in this way is by creating libraries.
To get up and running the quickest, you can literally change your entire project to a static library. Right click the project node, choose Properties, click General, and set Configuration Type to Static Library (.lib). Change your main function to be called something else like RunProgram(), make a header file and declare RunProgram() in the header file. I'll just call this header file foo.h, but make it something more appropriate.
Now create a new project, this time an Application (.exe). But do it by right clicking the root node in Solution Explorer and choosing Add -> New Project. When VS finishes creating it, you'll now have two projects in the same solution. In your new application project, add a #include "foo.h", then in main() simply call RunProgram().
To make it automatically link the library into the application, right click the project node of the application, choose Build Dependencies -> Project Dependencies, and then click the checkbox for the library. You'll probably need to set the include directories in your exe project to find the folder where the include files for the library are. This is in Project Properties -> C/C++ -> General -> Additional Include Directories.
In a production environment, you would probably create a more realistic separation between your driver / application and your core functionality that you're testing, instead of simply having your main() function be one line that calls the static library. For example, command line parsing, user input, etc would all be handled in the application while processing and utility libraries etc would be handled in the library.
In any case, when you've got all this working, creating the unit test suite is not much different than the application. Make a new Application, add a dependency, go to the Linker and Include settings and add the appropriate paths for gtest, then #include files from your library and start using them in yoru tests.
One common solution for handling the situation with include file paths is for a project to do something like this:
Code:
project
|__ project.sln
|__ src
|__ application
|__ main.cpp
|__ application.vcxproj
|__ library1
|__ lib1.cpp
|__ lib1.vcxproj
|__ library2
|__ lib2.cpp
|__ lib2.vcxproj
|__ include
|__ application
|__ library1
|__ lib1.h
|__ library2
|__ lib2.h
Now, in every project, you set your Additional Include folders to $(SolutionDir)include. Then in your application.cpp, you can simply write something like this:
#include "library1/lib1.h"
#include "library2/lib2.h"
And it will automatically find it. This way you dont' have to go manually screw around with the include path settings for every single project. It's always exactly the same value for every project, just "$(SolutionDir)include".
Anyway this is a lot to take in the first time you do it, but it's fairly intuitive once you get used to it.
I thought it may be todo with colors overflowing as (at the moment) I am using an unsigned byte to represent each color channel. However, I did add code to check for that so that doesn't seem to be the issue. The only problem is that I really don't know what it could be.