Тестирование с помощью Moq, если метод внешней библиотеки называется

Question

Для проекта я использую класс CompositeContainer структуры MEF. Теперь я хотел бы сделать модульный тест (с moq), который проверяет, вызван метод ComposeParts (который является методом расширения в AttributedModelServices).

Просто издевательство с помощью moq не работает, потому что метод не является виртуальным. Я нашел несколько способов сделать это, но все они заставляют меня менять класс CompositeContainer, чего я не могу сделать.

Есть ли способ в moq, чтобы проверить, вызывается ли не виртуальный метод внешней сторонней библиотеки?

Заранее благодарим за ваш ответ.

пример кода:

public void Load(string path, CompositionContainer container) 
{   
    container.ComposeParts(this);   
} 

Здесь контейнер из MEF библиотеки и ComposeParts метод расширения в System.ComponentModel.Composition имен:

// 
// Summary: 
//  Creates composable parts from an array of attributed objects and composes 
//  them in the specified composition container. 
// 
// Parameters: 
// container: 
//  The composition container to perform composition in. 
// 
// attributedParts: 
//  An array of attributed objects to compose. 
public static void ComposeParts(this CompositionContainer container, params object[] attributedParts); 

Answer 1

Я не считаю, что можно прямо проверить, был ли вызван метод сторонней библиотеки с помощью Moq, но вы можете проверить побочные эффекты вызова метода. Поскольку вы используете MEF для извлечения реализаций во время выполнения, я бы тестировал, что ваши типы были загружены правильно. Так что если у вас есть что-то вроде этого:

public interface IInterfaceToCompose 
{ 
    string MethodToCreate(); 
} 

[Export(typeof(IInterfaceToCompose))] 
public class ConcreteImplementation1 : IInterfaceToCompose 
{ 
    public string MethodToCreate() 
    { 
     return "Implementation 1"; 
    } 
} 

[Export(typeof(IInterfaceToCompose))] 
public class ConcreteImplementation2 : IInterfaceToCompose 
{ 
    public string MethodToCreate() 
    { 
     return "Implementation 2"; 
    } 
} 

Вы могли бы написать тест, который выглядит примерно так:

[ImportMany(typeof(IInterfaceToCompose))] 
public IInterfaceToCompose ComposedItems { get; set; } 

[Test] 
public void WhenComposingTheComposedItems_ShouldLoadExportedTypes() 
{ 
    Load("testPath", YourContainer); 

    Assert.AreEqual(2, ComposedItems.Count()); 
} 

То, что вы действительно хотите проверить (ИМО) является то, что вы создали свои составленные классы правильно и что все они могут быть загружены MEF CompositionContainer.

Хорошим вторым тестом было бы выполнить начальную загрузку, добавить DLL с третьим разработчиком и убедиться, что конечный счет равен 3 (ваша система динамически загружает новые модули). Это приведет к ошибкам, таким как забывание атрибутов новых реализаций с атрибутом Export, а также убедитесь, что ваши классы правильно подбирают изменения по мере их возникновения.

Answer 2

Это метод Load, реализованный в классе ? Вы решили удалить его оттуда? Принимая во внимание принцип единой ответственности, похоже, что ваш класс делает слишком много.

Я бы предложил, чтобы вы разделили функциональность - ваш класс делает любую бизнес-логику, в которой он нуждается. И еще один класс «инфраструктуры», который отвечает за компоновку контейнера - в вашем случае получить экземпляр вашего класса и зарегистрировать его в контейнере.

У вас будет почти такая же проблема, но в другом месте. И это «новое» место будет гораздо более сфокусированным на его функциональности, и вы можете протестировать его изолированно, используя реальный контейнер и изучить его, если будут созданы правильные части.

Answer 3

Если вы хотите просто проверить, что метод вызывается, вы можете обернуть CompositionContainer в интерфейсе оболочки, который называется ICompositionContainer, который имеет те же сигнатуры метода. Затем с Moq можно утверждать, что метод был назван:

mock.Verify(cc => cc.ComposeParts(), Times.Once()); 

Отрицательная здесь является то, что вы создаете интерфейс, чтобы скрыть тот факт, что первоначальная реализация не осуществлять для вас.

Пример кода теперь будет:

public void Load(string path, ICompositionContainer container) 
{   
    container.ComposeParts(this);   
} 

Есть примеры других проектов, которые обертывают проблематичным тестовые классы в рамках .NET, такие как SystemWrapper.