Given a standard interface, how to retrieve all implementing classes and run the interface methods.
Unit testing through test driven development is definitely a good idea; but what if you have a number of methods that all effectively do the same thing; that is, each method might do something completely different, but as far as it’s interface goes, it’s identical.
Imagine, for example, that you have a method that calls to the DB, and accepts a number of parameters in, and returns a given parameter. In a unit testing scenario, the DB would be mocked out, and the method called directly from the unit test. Okay, so in this case, you may want some test coverage that your methods call a mocked out DB function, don’t crash, accept a given object, accept null, etc…
Facing the same problem, it occurred to me that it should be possible to write a single test method that would test every existing and future implementation of this, without having to laboriously re-create the test each time I create a method; what’s more, as soon as I create my method name that implements the interface, I get a failing test.
Below is an interface and a test class; it is entirely for the purpose of illustration:
public class ModelClass
{
public string TestProperty { get; set; }
}
public interface ITest
{
void method1();
void method2(ModelClass model, int i);
}
public class Class1 : ITest
{
public void method1()
{
}
public void method2(ModelClass model, int i)
{
if (model == null) throw new Exception("test");
//if (string.IsNullOrWhiteSpace(model.TestProperty)) throw new Exception("Doh");
}
}
public class Class2 : ITest
{
public void method1()
{
//throw new NotImplementedException();
}
public void method2(ModelClass model, int i )
{
}
}
public class Class3
{
public void NonInterfaceMethod(ModelClass model)
{
throw new Exception("Doh!");
}
}
public class Class4 : ITest
{
public void method1()
{
//throw new NotImplementedException();
}
public void method2(ModelClass model, int i)
{
}
public void test()
{
}
}
As you can see, there are a number of interface, and non-interface methods here. There’s nothing particularly interesting, although have a look at Class1.method2(), which should do nothing, but switching the statements should cause a runtime error, if my method works. Also, have a look at Class3.NonInterfaceMethod() - this should never be called, but will throw an exception if it is.
The following is the test code:
[TestMethod]
public void TestITestImplementations()
{
// Use reflection to get the available methods for the interface
Type desiredType = typeof(ITest);
Assembly assembly = desiredType.Assembly;
var interfaceMethods = desiredType.GetMethods();
// Iterate through each implementation of the interface
foreach (Type type in assembly.GetTypes())
{
if (desiredType.IsAssignableFrom(type) && !type.IsInterface)
{
// Where an implementation is found, instantiate it
// and build a list of available methods to call
var classInstance = Activator.CreateInstance(type, null);
var methods = type.GetMethods()
.Where(m => interfaceMethods.Any(i => i.Name == m.Name)
&& m.IsPublic
&& !m.DeclaringType.Equals(typeof(object)));
foreach(var method in methods)
{
// Establish the available parameters and pass them to the call
var p = method.GetParameters();
object[] p2 = p.Select(a => Activator.CreateInstance(a.ParameterType)).ToArray();
try
{
// Call the method and, where a value should be returned, ensure one is
object result = method.Invoke(classInstance, p2);
Assert.IsFalse(method.ReturnType != typeof(void) && result == null);
}
catch(Exception ex)
{
// Where an error is thrown, print a sensible error
Assert.Fail("Call failed: {0}.{1}\\nException: {2}",
type.Name, method.Name, ex);
}
}
}
}
}
The code above is relatively straight-forward and, if I’m being honest, is only a cursory test. It tests that the methods can be called without throwing an error and, where a value should be returned, checks that it’s not null.
Obviously, it might be perfectly valid that it is null, or an exception might be the desired behaviour. This code is basically just a starting point, but it does provide some very basic test coverage where otherwise, there might be none.
It is also true to say that the code doesn’t deal with overloads, which are not necessary in my particular circumstance.