Единичный тест в MVC

Question

Я использовал mvc5 и Entity Framework 6 в своем проекте. Я решил использовать MSTest в моем проекте, но у меня есть несколько вопросов.

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

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

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

Если я хочу, чтобы макет был весь класс, потребитель времени и вероятность ошибки высока.

Каков наилучший подход к тестированию в этой ситуации? Является ли блок тестированием хорошего выбора?

В большинстве случаев веб-сайт представляет собой единичный тест, например, формат телефонного номера или ... что-то подобное, где я могу найти правильный образец?

Answer 1

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

• для того, чтобы получить соответствующие мероприятия тестирования, необходимо Тестовые среды (по крайней мере один)
• модульное тестирование - - только один из (тестовых) уровней, который должен быть выполнен. Как вы знаете Unit testing все о самая маленькая проверяемая часть приложения и ничего больше. Если вам нужно охватить создание сложных объектов, использование и т. Д., Возможно, вам нужно будет рассмотреть еще один номер test level. Например, Integration Testing поможет вам с комбинированными частями вашего приложения и определить, правильно ли они работают вместе.

О части с

макета всего классом

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

класса имеет несколько зависимостей к другим классам

Например, я использую такой высмеивал объект Test и кэшировать его, так что он может быть повторно использован в других тестовых исполнениях. Здесь очень полезно Flyweight-design-pattern.

года назад мне пришлось работать над такими проектами (ASP .Net, Entity Framework и т.д.), и в ответ на

Каков наилучший подход для проверки в этой ситуации?

Чтобы установить серьезный Test process, это поможет вам с надежностью вашего программного обеспечения.

Answer 2

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

Если вы хотите выполнить модульное тестирование на своих контроллерах, сначала вы должны установить его зависимости к услугам, «слабо связанным» с использованием Injection Dependency.

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

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

• См "Iteration #4 – Make the application loosely coupled" для объяснения с примерами о том, как использовать инъекции зависимостей с контроллерами.

• См. "Iteration #5 – Create unit tests", для того, чтобы проинтегрировать тест ваших контроллеров. Также here вы найдете некоторые инструменты, чтобы высмеять сеанс и запросить данные для тестирования ваших контроллеров.

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

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