Limitations of using C++/CLI with NUnit

Question

This answer to a question about C++ unit test frameworks suggests a possibility that had not occurred to me before: using C++/CLI and NUnit to create unit tests for native C++ code.

We use NUnit for our C# tests, so the possibility of using it for C++ as well seems enticing.

I've never used managed C++, so my concern is are there any practical limitations to this approach? Are many of you doing this? If so, what was your experience like?

Answer 1

We do this all of the time. We have many assemblies written with C++/CLI and use C# and NUnit to test them. Actually, since our goal is to provide assemblies that work well with C#, doing this makes sure that we have accomplished that.

You can also write NUnit tests in C++/CLI and call unmanaged C++. Probably the best way is the keep your pure unmanaged C++ in a lib, and then make a test assembly that uses NUnit and links to the lib.

Answer 2

It works very well and gives you the benefit of having parameterised tests as well as a common test runner and framework if you're in a mixed environment.

There are two downsides, neither of which is serious for most cases:

1. If you're being really picky, the tests are no longer being run in a purely native environment so there's an outside possibility that something may work under test but fail at runtime. I think you'd have to be doing something fairly exotic for this to matter.

2. You rely on your C++ code being able to be included into a C++/CLI program. Sometimes this can have clashes with headers and it forces your code to build OK with UNICODE. In general, this is a good thing as it uncovers crufty bits of code (like inconsistent use of Ansi variants of Win32 calls). Bear in mind that it's only the headers being included so what it may well show is that you are exposing headers at too high a level - some of your includes should probably be within your cpp implementation files.

Answer 3

My experience is that it is not possible to use NUnit to test C++ native code through C++/CLI because you will have trouble loading and using native code.

I have tried using nunit to load a basic c++/cli test dll linked against "just thread" which is an implementation of the c++ standard thread library. Test dlls won't even load with the latest version of NUnit (2.6.2).

So definitely not the way to go!

Answer 4

I never used one, but isn't there a port? Perhaps http://cunit.sourceforge.net/documentation.html would work for you.

Answer 5

The biggest concern is the learning curve of the C++/CLI language (formerly Managed C++) itself, if the tests need to be understood or maintained by non-C++ developers.

It takes a minimum of 1-2 years of C++ OOP experience in order to be able to make contributions into a C++CLI/NUnit test project and to solve the various issues that arise between the managed-native code interfaces. (By contribution, I mean being able to work standalone and able to make mock objects, implement and consume native interfaces in C++/CLI, etc. to meet all testing needs.)

Some people may just never grasp C++/CLI good enough to be able to contribute.

For certain types of native software libraries with very demanding test needs, C++/CLI/NUnit is the only combination that will meet all of the unit testing needs while keeping the test code agile and able to respond to changes. I recommend the book xUnit Test Patterns: Refactoring Test Code to go along this direction.