Partial Classes

When I first saw that .NET 2 supported partial classes, I groaned. It
looked like a language feature that helps one thing and hurts a dozen
more, once people start abusing it. However, I've come around to appreciate (and dare I say it, like) partial classes. They are obviously useful for code generation (which is why, I suspect) they were added in the first place). However, they are also handy for other problems.

Testing is one place where partial classes offer a better solution than the one offered by Visual Studio.NET 2005. In VS.NET, if you want to use MS-Test to test a private method, the tool uses code generation (without partial classes) to create a public proxy method that turns around and calls the private method for you using reflection. This is not a big surprise; the JUnitX add-ins in Java help you do the same thing. But using code gen for this is a smell: if you change your private method using reflection, the generated code isn't smart enough to change, so you have to do code gen again, potentially overwriting some of the code you've added. Yuck.

Here's a better solution. I should add parenthetically that I don't usually bother testing private methods (especially if I have code coverage) because the public methods will exercise the private ones (otherwise, the private methods shouldn't be there). However, when doing TDD, I sometimes want to test a complext private method. And partial classes work great for this. The example I have here is a console application that does some number factoring (why isn't important in this context). I have a method theFactorsFor() that returns the factors for an integer. Here is the PerfectNumberFinder class, including the method in question:

namespace PerfectNumbers {
   internal partial class PerfectNumberFinder {
       public void executePerfectNumbers() {
           for (int i = 2; i < 500; i++) {
               Console.WriteLine(i);
               if (isPerfect(i))
                   Console.WriteLine("{0} is perfect", i);
           }
       }

       private int[] theFactorsFor(int number) {
           int sqrt = (int) Math.Sqrt(number) + 1;
           List<int> factors = new List<int>(5);
           factors.Add(1);
           factors.Add(number);
           for (int i = 2; i <= sqrt; i++)
               if (number % i == 0) {
                   if (! factors.Contains(i))
                       factors.Add(i);
                   if (!factors.Contains(number/i))
                       factors.Add(number/i);
               }
           factors.Sort();
           return factors.ToArray();
       }

       private bool isPerfect(int number) {
           return number == sumOf(theFactorsFor(number)) - number;
       }

       private int sumOf(int[] factors) {
           int sum = 0;
           foreach (int i in factors)
               sum += i;
           return sum;
       }
   }
}

Rather than use code gen to test the method, I've made the PerfectNumberFinder class a partial class. The other part of the partial is the NUnit TestFixture, shown here:

namespace PerfectNumbers {
   [TestFixture]
   internal partial class PerfectNumberFinder {
      
       [Test]
       public void Get_factors_for_number() {
           int[] actual;
           Dictionary<int, int[]> expected =
               new Dictionary<int, int[]>();
           expected.Add(3, new int[] {1, 3});
           expected.Add(6, new int[] {1, 2, 3, 6});
           expected.Add(8, new int[] {1, 2, 4, 8});
           expected.Add(16, new int[] {1, 2, 4, 8, 16});
           expected.Add(24, new int[] {1, 2, 3, 4, 6, 8, 12, 24});

           foreach (int f in expected.Keys) {
               actual = theFactorsFor(f);
               for (int i = 0; i < expected[f].Length; i++)
                   Assert.AreEqual(expected[f][i], actual[i],
                                   "Expected not equal");
           }
       }
   }
}

I like this because it allows me to test the private method without any messy code generation, reflection, or other smelly work-arounds. Partial classes make great test fixtures because they have access to the internal workings of the class but don't have to reside in the same file. It's dangerous to pile infrastructure on new features like this (especially scaffolding-type infrastructure like classes), but this one seems like a more elegant solution to the problem at hand than stacks of code generation.