CODEWITHSUNDEEP
cvisual-studio-2010unit-testingdependency-injectionmanaged-c++
user545680
user545680

Reputation:

How can I unit test a managed wrapper around C code?

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.

Upvotes: 5

Views: 837

Answers (2)

k.m
k.m

Reputation: 31464

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?).

Upvotes: 1

Sebastian Weber
Sebastian Weber

Reputation: 6806

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.

Upvotes: 0

Related Questions