DISQUS

stephen · 7 months ago

Brilliant Idea, been looking for a straight forward solution to this scenerio that did not invlove using heavyweight reflection.

Jared · 5 months ago

Do you know of a way that you can do this with managed C++ that references unmanaged C++ types? Please see this question: http://stackoverflow.com/questions/916507/how-t...

eibrahim · 5 months ago

Sorry, but the last time I used c++ was in college :)

Doug de la Torre · 1 week ago

The downside to using PrivateObject is that it is a bit painful to maintain, since signature changes are not caught at compile-time, but instead caught at test-time. Refactorings that change method signatures tend to catch all the compile-time stuff, but then leave test code broken, and it is tougher to fix.

An alternative that I've always liked is to use inner-classes to test your code, like this:

public class Foo
{
private void Bar()
{
// Do so work here in a private method
}

#region Unit Tests
#if UNIT_TESTS
[TestFixture] public class TestFoo
{
[Test] public void TestBar()
{
Foo foo = new Foo()
foo.Bar(); // inner class can call this method
}
}
#endif
#end region
}

You simply define UNIT_TESTS in Debug/Release builds if you want test code enabled, and leave it out from your Ship builds.

Also, you'll probably have a using statement wrapper,

#if UNIT_TESTS
using MbUnit.Framework;
#endif

As an added check, you can write a simple app that does reflection on all the types in the DLL to verify your ship build doesn't have any classes with test attributes. If no code references the test framework, your ship builds will automatically not load the referenced test framework DLLs, thus allowing you to ship your product like usual without pulling in test DLL dependencies (and associated bloat and licensing issues).

eibrahim · 1 week ago

That's a pretty good idea except for the fact that it "pollutes" the
code.