TDD Arrange Act Assert шаблон при использовании Mocks для проверки вызовов зависимостей - PullRequest
Новая
       13

TDD Arrange Act Assert шаблон при использовании Mocks для проверки вызовов зависимостей

10 голосов
/ 22 декабря 2011

Я использую Moq для проверки поведения некоторых пустых методов.При использовании MockBehaviour.Strict каждый вызов макета должен быть указан на шаге Arrange.Это приводит к тому, что во многих тестах нет шага Assert (или проверки).Условие прохождения состоит в том, что тест выполняется без исключения.Я что-то пропустил?Является ли шаблон Arrange, Act, Assert неподходящим при использовании строгих макетов?Есть ли более семантический способ размещения этих тестов?

Тривиальный пример ... 

[TestClass]
public void DeleteUser_ShouldCallDeleteOnRepository()
{
    // Arrange
    var userRepository = new Mock<IUserRepository>(MockBehavior.Strict);

    int userId = 9;
    userRepository.Setup(x => x.Delete(userId));

    var controller = new UserController(userRepository.Object);

    // Act
    controller.DeleteUser(userId);

    // Assert
    // ...?
}

1 Ответ

24 голосов
/ 22 декабря 2011

Ваша насмешка занимает место соавтора.В идеале он делает одну из двух вещей:

  • Предоставление информации или данных
  • Выполнение работы

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

Когда макет выполняет работу, делегирование может быть проверено .Вот почему у вас есть Assert .

То, что вы делаете со строгим взаимодействием, - это обеспечение того, чтобы ожидалось каждое отдельное взаимодействие, в основном говоря: «Вот что я ожидаю, и есличто-нибудь еще случается, это неправильно. "Это другой вид тестирования для Act, Arrange, Assert, который говорит: «В этом контексте, когда я делаю это, я должен получить такой результат».

С «милой» насмешкой вынужно беспокоиться только о взаимодействиях, которые вас интересуют. Так, например, если я являюсь контроллером и ищу какую-то информацию в одном репозитории, проверяю ее с помощью валидатора, а затем сохраняю результат в другом репозитории,У меня может быть несколько тестов:

  • один, чтобы проверить, что я проверяю правильную информацию
  • один, чтобы проверить, как я реагирую на неправильную проверку
  • и один, чтобы проверить, что я сохраняю элемент.

При строгой насмешке вы должны выполнить все ожидания, даже если все, что вас интересует, это "сохранить"».Используя симпатичный макет, мы можем разделить различные аспекты поведения и сосредоточиться только на одном из них в каждом тесте.

В качестве дополнительного бонуса, симпатичные макеты позволяют вам:

  • Учитывая контекст
  • Когда это событие происходит
  • Тогда этот результат должен произойти

В то время как строгие насмешки заставляют вас делать:

  • Учитывая контекст
  • Ожидайте, что что-то случится
  • Когда я выполню событие
  • Затем вернитесь и прочитайте, каким должен был быть результат.

Первый из них обычно считается более читабельным.

...