Take the 2-minute tour ×

I will be creating a Managed-C++ wrapper around some C functions to allow its use in other .NET solutions. I'm looking at providing a very minimalist wrapper, something like:

Signature in C header:

void DOSTH(const char*, short, long*);

Exposed managed interface:

public void doSomething(String^ input, short param, [Out] long^ %result);

To do so my solution will have the C headers and will reference the .dll that contains the compiled C API that I am building against.

As a Visual Studio newbie I'm unsure how I would unit test this. Is it possible to mock out the .dll to provide a mock implementation? Is there a library that would make this kind of task easy? Is there a particular solution structure I should aim for to make this easier?

Any guidance in this area would be great. Google searches have left me wanting for more info on unit testing a managed wrapper.

share|improve this question
add comment

2 Answers

In some cases (tools limitations and/or dependency complexity comes to my mind), mocking dependency using external frameworks is out of question. Then, there's totally legitimate technique of writing mocks manually (I think that was the way to do stuff before mocking frameworks grew in popularity).

And that's basically what you want to do - fake out dependency, which in your case happens to be C library. Frameworks can't help - you might want to try manual approach.

Create some simple, faked implementation (pretty much like a stub, eg. only returning fixed values regardless of input params - naturally, might be more sophisticated than that), compile it, let it expose exactly the same headers/functions and reference it in your test project. That's the essential idea behind faking (stubbing/mocking) - one object pretending to be another.

As simple as it sounds, I haven't actually tried that - take it with a grain of salt and more as a suggestion which way you could go. Limitation of this approach (apart from whether it actually is technically possible) is very poor/none configuration options (since the extra faked DLL would act like a hardcoded stub - configuration files could help, but that feels like... too much work?).

share|improve this answer
That is always an option. I guess I can take that approach if tools like Cgreen can't be used in my context. –  Bringer128 Jan 24 '12 at 1:34
@Bringer128: out of curiosity, how do you plan on using Cgreen here? I've seen they provide quite nice mocking utilities, but that essentially narrows down to faking that DLL? Or am I missing something obvious here? –  jimmy_keen Jan 24 '12 at 23:38
I'm pretty sure that mocking the DLL is the only way to do it. I'll have to experiment first, I'll report back when I've found something. –  Bringer128 Jan 25 '12 at 1:34
add comment

Do you only need to be able to stub/mock out your wrapper so that your tests don't rely on the native dll?

Then you can declare an abstract base class for your wrapper, write one implementation that calls the native dll and another one for testing purposes that returns canned values. Or you can use a framework like Moq or Rhino.Mocks to mock your wrapper.

share|improve this answer
Unfortunately not - that part is much easier. I'm looking for a way to test my wrapper, not the code that uses my wrapper. –  Bringer128 Jan 16 '12 at 7:19
Then you would have to add your wrapper and the native dll to your test project in the exact same way you would have to add it to all applications that will use it later. Personally I try to avoid using native assemblies whenever possible. The problems with deployment, (automated) builds, wrong platform (x86 vs. x64) and missing native assemblies that crash your application at runtime are often not worth the trouble. –  Sebastian Weber Jan 16 '12 at 8:02
add comment

Your Answer


