Как выполнить модульное тестирование метода Create в MVC5? [Дубликат]

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

Я предпочитаю тесты интеграции - я начинаю не с конкретного контроллера, а с URL-адреса, и проверяю, что возвращаемая модель имеет правильные значения. С помощью Ivonna тест может выглядеть так:

var response = new TestSession().Get("/Users/List");
Assert.IsInstanceOf<UserListModel>(response.Model);

var model = (UserListModel) response.Model;
Assert.AreEqual(1, model.Users.Count);

Я могу издеваться над доступом к базе данных, но я предпочитаю другой подход: настройте экземпляр в памяти SQLite и воссоздать его с каждым новым тестом вместе с требуемыми данными. Это делает мои тесты достаточно быстрыми, но вместо сложного насмешки я делаю их понятными, например. просто создайте и сохраните экземпляр пользователя, а не издевайтесь над файлом UserService (который может быть деталью реализации).

Вы должны сначала поставить свои контроллеры на диету. Затем вы можете повеселиться , проверяя их. Если они толстые, и вы вложили в них всю свою бизнес-логику, я согласен, что вы будете проходить свою повседневную музыку в своих модульных тестах и ​​жалуетесь, что это пустая трата времени.

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

Да, вы должны полностью протестировать базу данных. Время, в которое вы насмехаетесь, меньше, и ценность, которую вы получаете от насмешек, очень меньше (80% вероятных ошибок в вашей системе нельзя отбросить из-за насмешек).

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

Вот как это работает для нашей команды. Каждый тестовый класс в начале восстанавливает БД и заполняет / сортирует таблицы с минимальным набором данных (например, роли пользователя). На основе потребностей контроллеров мы заполняем БД и проверяем, выполняет ли контроллер его задачу. Это спроектировано таким образом, что поврежденные DB данные, оставленные другими методами, никогда не завершится. За исключением времени, которое нужно выполнить, почти все качества модульного теста (хотя это и есть теория) являются gettable.

В моей карьере было всего 2% ситуаций (или очень редко), когда меня заставили использовать mocks / stubs, так как не удалось создать более реалистичный источник данных. Но во всех других ситуациях интеграционные тесты были возможны.

Нам потребовалось время, чтобы достигнуть зрелого уровня с помощью этого подхода. у нас есть хорошая структура, которая касается совокупности и поиска тестовых данных (граждан первого класса). И это окупает большое время :). Первый шаг - попрощаться с издевательствами и модульными тестами. Если насмешки не имеют смысла, то они не для вас! Тест интеграции дает вам хороший сон

============================================

Отредактировано после комментария ниже: Демо

Интеграционный тест или функциональный тест должен иметь дело непосредственно с БД. Никаких насмешек. Итак, это шаги. Вы хотите проверить getEmployee (). все эти 5 шагов ниже выполняются одним методом испытаний.

1. Drop DB
2. Создать БД и заполнить роли и другие данные
4. Создать запись сотрудника с идентификатором
5. Использовать это ID и вызов getEmployee ()
6. Now Assert () / Проверить правильность возвращаемых данных. Это доказывает, что работает getEmployee (). Шаги до 3 требуют, чтобы код использовался только тестовым проектом. Шаг 4 вызывает код приложения. То, что я имел в виду, это создание сотрудника (шаг 2), должно выполняться кодом кода проекта, а не кодом приложения. Если для создания сотрудника существует код приложения (например: CreateEmployee ()), это не должно использоваться. Точно так же, когда мы тестируем CreateEmployee (), тогда код приложения GetEmployee () не должен использоваться. Мы должны иметь тестовый код проекта для извлечения данных из таблицы.

Таким образом, нет никаких издевок! Причиной отказа и создания БД является предотвращение ошибочных данных БД. С нашим подходом тест пройдет независимо от того, сколько раз мы его запускаем.

Специальный совет: на шаге 5, если getEmployee () возвращает объект employee. Если позднее разработчик удаляет или изменяет имя поля, тест прерывается, потому что поля проверяются. Что делать, если разработчик добавит новое поле позже? И он / она забывает добавить тест для него (утверждать)? Решение состоит в том, чтобы всегда добавлять проверку количества полей. например: Объект Employee имеет 4 поля (Имя, Фамилия, Обозначение, Пол). Таким образом, количество полей объекта сотрудника - 4. И наш тест завершится неудачно из-за подсчета и напомнит разработчику добавить поле подтверждения для вновь добавленного поля. А также наш тестовый код добавит это новое поле в БД и получит его и проверит.

И это отличная статья, в которой обсуждаются преимущества тестирования интеграции над модульным тестированием , потому что «модульное тестирование убивает!» (говорит он)

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

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

Целью единичного теста является проверка поведения метода по отдельности на основе набора условий. Вы устанавливаете условия теста с помощью mocks и утверждаете поведение метода, проверяя, как он взаимодействует с другим кодом вокруг него - проверяя, какие внешние методы он пытается вызвать, но особенно, проверяя значение, которое он возвращает, учитывая условия.

Поэтому в случае методов Controller, возвращающих ActionResults, очень полезно проверить значение возвращаемого ActionResult.

Посмотрите раздел «Создание модульных тестов для контроллеров» ' здесь для некоторых очень четких примеров с использованием Moq.

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

[TestMethod]
public void CreateInvalidContact()
{
    // Arrange
    var contact = new Contact();
    _service.Expect(s => s.CreateContact(contact)).Returns(false);
    var controller = new ContactController(_service.Object);

    // Act
    var result = (ViewResult)controller.Create(contact);

    // Assert
    Assert.AreEqual("Create", result.ViewName);
}