Wakan Tanka
Wakan Tanka

Reputation: 8052

Proper unit testing in Visual Studio

I have solution containing several C++/x64 projects. For one of this project I want to write unit tests. I'm following this tutorial and I'm using Visual Studio Community 2013. Hello world example from mentioned tutorial runs fine, but if I create test project inside my larger solution which contains multiple projects then I get bunch of errors. Before I will go into deeper troubleshooting I would like to clarify a few questions that I've not found answers for:

  1. If I have multiple tests projects how does Test -> Run -> All Tests knows which one to run?

  2. Should I exclude projects that I do not want to test via: Right click on solution name -> Properties -> Configuration

  3. If I have projects that are to be build under x64 should I set Test -> Test Settings -> Default Processor Architecture -> x64?

  4. Is it important if my StartUp project (Right click on project name -> Set as StartUp Project) is tested project or testing project?

  5. I've noted that my test project has platform win32 while tested project has x64 under Right click on solution name -> Properties -> Configuration is this OK?

PS: I'm running tests via Test -> Run -> All Tests

Upvotes: 0

Views: 58

Answers (1)

Sebastian Redl
Sebastian Redl

Reputation: 72063

  1. It runs all tests it can find. It finds tests via test runner plugins, which are invoked whenever a project finishes building to see if it contains any tests.
  2. Why do you have projects that you don't want to test in your solution? I don't think there's a simple way to exclude a project from testing, aside from unloading it.
  3. It should not be necessary, but if you run into problems, it's worth trying.
  4. No, test runners ignore the starting project.
  5. Depending on how your projects are set up, this may be either slightly wrong or completely wrong.

Let me elaborate on that last point. There are two typical ways to set up unit tests in C++.

One is to have your executable project with all its files, and then you have the test project which also contains all the source files of the main project except for the file containing the entry point, and also contains the test files.

This has the downside of you having to manage those files, i.e. when you add a new file to the project, you have to add it to both projects. It also means that the compiler will compile all those source files twice, once for each project.

It also means that if the two projects have differing configurations (x64 vs Win32) it works. That is not fully an upside, because you generally want to test the same thing you're actually delivering, and testing a 32-bit build of your code is not useful in finding bugs that only happen in 64-bit builds.

The other option is to have three projects: a library containing most of the source code (I prefer static libraries, though DLLs are an option), a main project that just contains the entry point, and a test project that contains only the test files. The two latter link against the first.

This means that all code is only compiled once, and that you test the exact same thing you're delivering.

In this case, all project configurations have to match. If they don't, you get build errors with potentially confusing error messages at best ("I just wrote this function, what do you mean you can't link it?"), and links against stale versions of the library ("I put a debug printf in that function, why isn't it printing?") at worst.

Upvotes: 1

Related Questions