Most classes have private methods. DeveloperTests cover behaviors, not methods. Some behaviors will ReFactor into private methods, as their public access points grew too long. So their tests are indirect.
Related Wiki Pages:
Yahoo Groups (was Egroups):
To retrofit unit tests into legacy code sometimes you must crack open a "seam", and publicize your private methods. (Code designed without TestDrivenDevelopment can sometimes link into itself a little too incestuously.)
Sigh - introducing a seamd be so easy if C# supported ConditionalCompilation?, so you can do this without cluttering up the code view:
#if (UNITTEST) public void myMethod() #else private void myMethod() #endif { ... method body ... }You can leave it private and call it via reflection from your test. Gives you a bit more to code in the test, but leaves the implementation clean.
Actually a technique I've used in unit testing private members in C++ is:
#define protected public #define private public #include "TheClassHeaderUnderTest?.h" #undef protected #undef privateRather dirty but it does give access. (And note, if you don't totally rebuild with the same definitions over "TheClassHeaderUnderTest?.h" for an entire executable before linking, you will violate C++'s One Definition Rule.)
See discussion on UnitTestingNonPublicMemberFunctions. -- OliverKamps