14 May, 2009 § 8 Comments
I’ve just finished getting an implementation going of MSTest with GMock, and I wanted to document all things neccessary to use GMock in a testing framework other than GTest.
To get GMock to build in VS2008, I had to install the Visual Studio 2008 Feature Pack. This was so I could get full TR1 support, specifically
std::tr1::tuple. Other coworkers of mine haven’t needed to install the Feature Pack, though I presume that they didn’t need to because they had SP1 installed (which I thought I had installed). After installing the Feature Pack, I then had to reinstall SP1 due to some odd compiler errors that were occurring due to mismatched compiler versions.
Now some quick gotchas with GMock:
- If you use the included gmock_gen.py script to generate your mocks from your pure abstract classes, then you will need to make sure that there are no default arguments in any of your mock’s methods.
- When you add expectations to a mock, you should call
VerifyAndClearExpectationsat the end of your test method. You should assert that this method returns True. If you don’t include this method call, then your testing framework won’t be able to catch the GTest exceptions that will get thrown if the GMock’s expectations aren’t met.
Those are the only points I wanted to put out there at this point. When I run in to more bumps in the road I’ll be sure to publish them.
6 May, 2009 § 20 Comments
Visual Studio 2008 offers the built in ability to write unit tests in C# by creating a Test Project. This same feature applies to managed C++, otherwise known as C++/CLI. If you are working on a project in MFC and would like to get the same unit test integration that is built directly in to Visual Studio, there is a way. Here are the steps you will have to follow:
- Create a C++ Test project within your solution.
- Open up the Properties of the project and change the Common Language Runtime support from /clr:safe to /clr. This will allow you to execute code from both C++/CLI and simple C++.
- Set the project to link to MFC using a shared DLL. You cannot compile with both /clr and statically linking to MFC.
- Edit the test project’s dependencies and add a dependency on the MFC project that you would like to unit test.
You should be all good here, except for one large gotcha. The unit test project will have its own instance of CWinApp declared. If the MFC project that you would like to test against also has its own instance of CWinApp, then everything will get confused and the tests won’t start. To solve this, you will have to create a separate MFC DLL project and move your code to this project. Your test project should now have a dependency on this new MFC DLL project, and not your previous one. If you would still like your application to produce a single executable, just make sure that the previous project statically links against the MFC DLL that you have just created.
Let me know if you have any questions. I’ve spent the last couple days getting this scenario to work.
(I’m using GoogleMock with my unit tests, and I think that the combination of MSTest and GoogleMock is perfect. The integration with Visual Studio that MSTest provides, and the ease to make mocks with GoogleMock makes writing C++ unit tests a walk in the park. I should be putting up a simple tutorial on using GoogleMock in the future.)