Unit testing MFC with MSTest

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:

1. Create a C++ Test project within your solution.
2. 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++.
3. Set the project to link to MFC using a shared DLL. You cannot compile with both /clr and statically linking to MFC.
4. 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.)

Resolving error C2248 with CObject

Ever come across this error before?

error C2248: 'CObject::CObject' : cannot access private member declared in class 'CObject'

It can be a frustrating error to try and diagnose. Try commenting out all the code you’ve added since your last checkin and the error is still there? Most likely, this is happening due to a copy constructor being called on an object that derives from CObject. If you are returning a CObject by value, then the copy constructor will be implicitly called. To solve this, either return it by reference or by const-reference, which ever applies to the situation.

This means if you have this:

CProgressCtrl CMyWindow::GetProgressDialog() { ... }

You should change it to this:

void CMyWindow::GetProgressDialog( CProgressCtrl& progressCtrl ) { ... }

If you have this:

void CMyWindow::UpdateProgressDialog( int position, CProgressCtrl progressCtrl ) { ... }

You should change it to this:

void CMyWindow::UpdateProgressDialog( int position, const CProgressCtrl* progressCtrl ) { ... }

Thank you goes out to Nick Meyer. Sometimes the obvious reasons just get left out when trying to figure out why something doesn’t work.

MFC Dialog Data Exchange

I’ve been surprised to learn that there are developers who have worked in MFC for a long time and never really knew much about Dialog Data Exchange. I don’t fault them, since the easiest way to stumble upon it is through the Forms Designer’s context menu (besides seeing it in the generated code and having no clue what it does).

Dialog Data Exchange (DDX) is a really nifty feature that MFC brought forward to use when working with user interfaces. DDX strongly types variables and controls in the Dialog/Form’s associated class to the objects found in the UI.

This means you can get rid of GetDlgItem. Why does this help? Besides removing code and tons of enums interspersed throughout your code, it allows the ability to subclass a control easily with minimal code changes. Here is a short example: