I was reading and found this code as an aswer to a question
public List<T> LoadPlugin<T>(string directory)
{
Type interfaceType = typeof(T);
List<T> implementations = new List<T>();
//TODO: perform checks to ensure type is valid
foreach (var file in System.IO.Directory.GetFiles(directory))
{
//TODO: add proper file handling here and limit files to check
//try/catch added in place of ensure files are not .dll
try
{
foreach (var type in System.Reflection.Assembly.LoadFile(file).GetTypes())
{
if (interfaceType.IsAssignableFrom(type) && interfaceType != type)
{
//found class that implements interface
//TODO: perform additional checks to ensure any
//requirements not specified in interface
//ex: ensure type is a class, check for default constructor, etc
T instance = (T)Activator.CreateInstance(type);
implementations.Add(instance);
}
}
}
catch { }
}
return implementations;
}
and it got me wondering what the best way to unit test this code would be?
There are three unrelated things that are done in that one method (see SRP). Each of them should be separated to their own class, which implements some interface, so that you can mock them for better testability. The tree things are:
Finding out the .dll files from the plugin directory.
Loading the .dll and getting the types that it contains. This should be a one-liner that calls the API methods. You don’t really need to test this (at least not in unit tests), because you can reasonably assume that the programming language’s libraries work right.
Creating instances of the plugin types.
When the algorithm is separated into these three parts, you can unit test parts 1 and 3 in isolation (although technically the tests for part 1 are not unit tests, because it touches the file system, unless C# has some way to mock the file system, like Java 7’s NIO2 file system API should be mockable). You can also unit test the code that puts them all together, by mocking part 2.