Unit testing a C++/CLI Wrapper

Pages: 1 2 3

Normally the software projects I worked in never consisted of a proper unit testing phase. What we did all these years was not UT but IT ( integration testing ). Some people still oppose when I say you can’t unit test a code without completely isolating the method under test. This is probably due to their lack of knowledge or something related to the rocket science that I still don’t know. In either case, I love to direct them to this one book called “The art of Unit Testing by Roy Oshervoe”. In one project, I got an opportunity to study about unit testing and submit a report on whether it is feasible under the current workflow.The knowledge gained from that particular assignment, I consider precious.

What I’m going to talk about is not about unit testing in general. I suggest you to take a look at that book I mentioned to get a good picture of current unit testing methods etc; Ignore if you already know. During my assignment, while trying out different techniques like dependency injection in my project scenario, I come across a difficult situation. I was testing a C++/CLI wrapper for a module in C++.  Its basically an adapter that marshals the native C++ types in to corresponding C# types and vice versa. Wrappers normally have little or less logic. But, there are some ‘if’s and ‘while’s involved even though that counts as the conversion logic only. To ensure nearly a complete code coverage, I need to test those minute details too. Dependency to the module that is being wrapped is obvious. I need to get rid of it in order to test it.

A typical C++/CLI Wrapper

A normal dependency breaking scenario consists of two classes that are coupled together that we use inversion of control(IoC) to loosen the coupling. IoC is a process by which the assembler binds the object coupling at run-time. Normally we achieve this through Dependency Injection, where the interface or base class of the dependent class is injected via the constructor or setter functions. [Contd. See next page]

CWnd::ShowWindow Can’t always Hide your Window!

CWnd::ShowWindow as most think is perhaps the most used member function in CWnd the basic MFC window class. Sticking heavily to MFC has its disadvantages. Before coming to that, let me say this. SW_SHOW and SW_HIDE aren’t the only values that can be passed to the function.

• SW_HIDE: Hides this window and passes activation to another window.
• SW_MINIMIZE: Minimizes the window and activates the top-level window in the system’s list.
• SW_RESTORE: Activates and displays the window. If the window is minimized or maximized, Windows restores it to its original size and position.
• SW_SHOW: Activates the window and displays it in its current size and position.
• SW_SHOWMAXIMIZED: Activates the window and displays it as a maximized window.
• SW_SHOWMINIMIZED: Activates the window and displays it as an icon.
• SW_SHOWMINNOACTIVE: Displays the window as an icon. The window that is currently active remains active.
• SW_SHOWNA: Displays the window in its current state. The window that is currently active remains active.
• SW_SHOWNOACTIVATE: Displays the window in its most recent size and position. The window that is currently active remains active.
• SW_SHOWNORMAL: Activates and displays the window. If the window is minimized or maximized, Windows restores it to its original size and position.

Here, window activation, whether you need it or not is an important thought. Now here is the point. You can’t do any of these to a window created in a different thread. CWnd doesn’t have a function for this purpose. Its object oriented policies doesn’t allow it to have one I guess. A win32 API is here to save the day; ShowWindowAsync. This API can set the visibility state of a window created in another thread. So, if you are in a multi-threaded application be sure to use this API to hide or show your window in case of creation of the same from different threads.