Могу ли я реализовать серию повторно используемых тестов для проверки реализации интерфейса?

Да, это возможно. Хитрость заключается в том, чтобы позволить вашей иерархии тестов модульного класса следовать иерархии классов вашего кода.

Предположим, у вас есть интерфейс Itf с реализацией классов C1 и C2.

Сначала вы создаете тестовый класс для Itf (ItfTest). Чтобы на самом деле выполнить тест, вам нужно создать фиктивную реализацию вашего интерфейса Itf.

Все тесты в этом ItfTest должны проходить на любой реализации Itf (!). Если нет, ваша реализация не соответствует принципу подстановки Лисков ("L" в SOLID принципы объектно-ориентированного проектирования)

Таким образом, чтобы создать тестовый пример для C1, ваш класс C1Test может расширять ItfTest. Ваше расширение должно заменить создание фиктивного объекта созданием объекта C1 (внедряя его или используя GoF заводской метод). Таким образом, все случаи ItfTest применяются к экземплярам типа C1. Кроме того, ваш класс C1Test может содержать дополнительные тестовые примеры, специфичные для C1.

Аналогично для C2. И вы можете повторить этот трюк для более глубоко вложенных классов и интерфейсов.

Ссылки: биндер шаблон Polymorphic Server Test и PACT — параллельная архитектура для тестирования компонентов.

Расширяя ответ Джо, вы можете использовать атрибут [TestCaseSource] в NUnit аналогично RowTest MBUnit. Вы можете создать источник тестового примера с именами ваших классов. Затем вы можете украсить каждый тест, который имеет атрибут TestCaseSource. Затем, используя Activator.CreateInstance, вы можете выполнить переход к интерфейсу, и все будет готово.

Что-то вроде этого (примечание — голова скомпилирована)

string[] MyClassNameList = { "Class1", "Class2" };

[TestCaseSource(MyClassNameList)]
public void Test1(string className)
{
    var instance = Activator.CreateInstance(Type.FromName(className)) as IMyInterface;

    ...
}

Для этого можно использовать атрибуты [RowTest] в MBUnit. В приведенном ниже примере показано, как вы передаете методу строку, указывающую, какой класс реализации интерфейса вы хотите создать, а затем создаете этот класс посредством отражения:

[RowTest]
[Row("Class1")]
[Row("Class2")]
[Row("Class3")]
public void TestMethod(string type)
{
   IMyInterface foo = Activator.CreateInstance(Type.GetType(type)) as IMyInterface;

   //Do tests on foo:
}

В атрибутах [Row] вы можете передать любое произвольное количество входных параметров, таких как входные значения для тестирования или ожидаемые значения, которые будут возвращены вызовами метода. Вам нужно будет добавить аргументы соответствующих типов в качестве входных аргументов тестового метода.

Это моя конкретная реализация, основанная на ответе avandeursen:

[TestClass]
public abstract class IMyInterfaceTests
{
    protected abstract IMyInterface CreateInstance();

    [TestMethod]
    public void SomeTest()
    {
        IMyInterface instance = CreateInstance();
        // Run the test
    }
}

Затем каждая реализация интерфейса определяет следующий тестовый класс:

[TestClass]
public class MyImplementationTests : IMyInterfaceTests
{
    protected override IMyInterface CreateInstance()
    {
        return new MyImplementation();
    }
}

SomeTest запускается один раз для каждого конкретного TestClass, полученного из IMyInterfaceTests. Используя абстрактный базовый класс, я избегаю необходимости в фиктивных реализациях. Обязательно добавьте TestClassAttribute к обоим классам, иначе это не сработает. Наконец, при желании вы можете добавить в дочерний класс любые тесты, специфичные для реализации (например, конструкторы).