Как скомпилировать диспетчер объектов

Question

Являюсь новым для модульного тестирования и просто начинаю писать модульные тесты для существующей базы кода.

Я хотел бы написать модульный тест для следующего метода класса.

public int ProcessFileRowQueue() 
    { 
     var fileRowsToProcess = this.EdiEntityManager.GetFileRowEntitiesToProcess(); 
     foreach (var fileRowEntity in fileRowsToProcess) 
     { 
      ProcessFileRow(fileRowEntity); 
     } 
     return fileRowsToProcess.Count; 
    } 

Проблема с GetFileRowEntitiesToProcess(); Платформа Entity Менеджер оберткой Entity Framework контекст. Я искал это и нашел одно решение - иметь тестовую базу данных из известного состояния для тестирования. Однако мне кажется, что создание нескольких объектов в тестовом коде даст более последовательные результаты теста.

Но, поскольку он существует, я не вижу способа издеваться над Менеджером без какого-либо рефакторинга.

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

Answer 1

Я слышу два вопроса:

Должен ли я Мок EdiEntityManager?

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

Как я могу издеваться над EdiEntityManager?

Что мы не можем знать из кода, опубликованного. Это зависит от того, что тип, как он создан и поставляется в этот объект, содержащий, и т.д. Для того, чтобы ответить на эту часть вопроса, вы должны попытаться:

1. Создать макет с известным поведением для один способ бытия вызывается (GetFileRowEntitiesToProcess()).
2. Inject, который издевается над этим тестируемым объектом.

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

В качестве примера предположим, что EdiEntityManager создается в конструкторе:

public SomeObject() 
{ 
    this.EdiEntityManager = new EntityManager(); 
} 

Это было бы что-то, что мешает насмешливый, потому что он получает в пути Шаг 2 выше. Вместо этого конструктор будет переработан требовать, а не Instantiate:

public SomeObject(EntityManager ediEntityManager) 
{ 
    this.EdiEntityManager = ediEntityManager; 
} 

Это позволило бы тест на поставку издеваться, и согласуется с Принцип инверсии зависимостей.

Или, возможно, EntityManager является слишком конкретным типом и сложным для издевательства/инъекции, тогда, возможно, фактический тип должен быть интерфейсом, который определяет EntityManager.Худший сценарий с этой проблемой может заключаться в том, что вы вообще не контролируете тип и просто должны определить объект-оболочку (который сам имеет макетный интерфейс), чтобы заключить в себе зависимость EntityManager.