It looks like you are aiming to develop unit testing for your solution(s), which is a good thing. It can be done in many different ways.
First of all, please read:
http://en.wikipedia.org/wiki/Unit_testing[
^].
First of all, you can create and add some test projects. Even though there are universal unit testing techniques which don't require creation of any application-specific test projects (please see below),
other types of testing and the whole development strategy may require them, so I'll give you some idea. Besides, it's a good idea to have some prototype projects.
So, it looks like testing some EXE seems to be a problem for you. Here, you should understand one simple thing: you can reference EXE (or any kinds of assemblies for that matter), exactly as DLLs. Essentially, for .NET, there are no EXEs and DLLs, there are just assembly. Any of those assemblies can be referenced by some test-project assembly. Now, a little problem is: if you use some types/members internally for the assembly, you should give them
internal
access specifiers, but using them from a referencing assembly required
public
. That said: 1) you can create special tests inside the assembly under the test and make them public, probably conditionally (depending on
#define
preprocessor conditions), or 2) you can use Reflection in your test projects, as Reflection can work regardless of access specifiers. As Reflection approach is more difficult, you may consider using some existing unit testing facility.
For a 3rd-party testing facility, I would recommend
open-source NUnit:
http://en.wikipedia.org/wiki/NUnit[
^],
http://www.nunit.org/[
^].
Your problem is greatly simplified by the fact that you only test .NET project. C++/CLI and C# project practically don't have any barriers between them. You can consider other facilities. Please see this list:
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#.NET_programming_languages[
^].
Basically, you create only the tests, which can be marked by special attributes. The utility finds the tests and perform testing automatically. It's your responsibility to provide a test set which is fairly comprehensive. And don't forget: testing along will never guarantee the correctness of your software.
—SA