Я думаю, что понимаю определение тестирования на основе состояния / взаимодействия (читайте статью Фаулера и т. Д.). Я обнаружил, что начал основываться на состоянии, но в большей степени основывался на взаимодействии, и я немного запутался в том, как тестировать определенные вещи.
У меня есть контроллер в MVC, и действие вызывает службу для отказа в пакете:
public ActionResult Deny(int id)
{
service.DenyPackage(id);
return RedirectToAction("List");
}
Мне кажется, это понятно. Предоставить фиктивный сервис, убедиться, что он был правильно вызван, выполнено.
Теперь у меня есть действие для представления, которое позволяет пользователю связать сертификат с пакетом:
public ActionResult Upload(int id)
{
var package = packageRepository.GetPackage(id);
var certificates = certificateRepository.GetAllCertificates();
var view = new PackageUploadViewModel(package, certificates);
return View(view);
}
На этот раз я немного озадачен. Я делаю тесты в стиле Spec (возможно, неправильно), поэтому для тестирования этого метода у меня есть класс, а затем два теста: убедитесь, что был вызван репозиторий пакетов, убедитесь, что был вызван репозиторий сертификатов. Я на самом деле хочу третий тест, чтобы убедиться, что конструктор был вызван, но я не знаю, как это сделать! У меня такое впечатление, что это совершенно неправильно.
Так что для тестирования на основе состояния я бы передавал идентификатор и затем проверял представление ActionResult. Хорошо, это имеет смысл. Но разве у меня не будет теста на конструктор PackageUploadViewModel? Поэтому, если у меня есть тест на конструкторе, то часть меня просто захочет убедиться, что я вызываю конструктор и что возвращаемое действие соответствует тому, что возвращает конструктор.
Теперь еще одна опция, о которой я могу подумать, это то, что у меня есть PackageUploadViewModelBuilder (или что-то с таким же тупым именем), который зависит от двух репозиториев, а затем я просто передаю идентификатор методу CreateViewModel или чему-то другому. Тогда я мог бы высмеять этот объект, проверить все и быть счастливым. Но ... ну ... это кажется экстравагантным. Я делаю что-то простое ... не простое. Кроме того, controller.action (id), возвращающий builder.create (id), выглядит как добавление слоя без причины (контроллер отвечает за построение моделей представлений .. верно?)
Я не знаю ... Я думаю, что необходимо больше тестирования на основе состояния, но я боюсь, что если я начну тестировать возвращаемые значения, то если метод А может быть вызван в 8 различных контекстах, у меня будет тестовый взрыв с большим количеством повторений. Я использовал тестирование на основе взаимодействия, чтобы передать некоторые из этих контекстов в метод B, чтобы все, что мне нужно было сделать, это проверить метод A, называемый методом B, и у меня был протестирован метод B, чтобы метод A мог просто доверять обработке этих контекстов. Таким образом, основанное на взаимодействии тестирование строит эту иерархию тестов, но тестирование на основе состояния собирается сгладить ее.
Понятия не имею, имеет ли это смысл.
Ух ты, это долго ...