Модульные тесты ASP.NET MVC - Поддельный репозиторий стал громоздким

Question

Все началось с моих поддельных репозиториев, которые содержали жестко закодированные списки сущностей.

По мере моего продвижения, мои общие поддельные репозитории стали раздутыми. Я постоянно добавляю новые свойства и новые объекты в эти списки. Это делает его чрезвычайно сложным в обслуживании и также трудно понять, что делает тест. Я считаю, что это анти-паттерн под названием " General Fixture ".

При исследовании модульных тестов ASP.NET MVC я видел два метода для подготовки креплений репозитория, которые передаются на контроллеры.

1. Создание жестко запрограммированных поддельных репозиториев, которые будут использоваться всеми тестами
2. Макет частей хранилищ в каждом тесте

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

Мой вопрос к сообществу ...

Какие методы для подготовки репозитория работают лучше, чем примитивные примеры?

Answer 1

Не думаю, что вам следует выбирать только один из двух вариантов.Есть случаи, когда использование поддельного хранилища было бы лучше, и бывают случаи, когда издевательство было бы лучше.Я думаю, что вы должны оценить, что вам нужно в каждом конкретном случае.Например, если вы пишете тест для UsersService, который должен вызывать IUserRepository.DoesUserExist(), который возвращает логическое значение, то вы не будете использовать поддельный репозиторий, проще просто смоделировать вызов, чтобы вернуть истину или ложь.*

Мок потрясающе.

Answer 2

Если вы используете свои модульные тесты для TDD, скачайте Rhino Mocks и используйте optione # 2.

Answer 3

По аналогичной причине в новом проекте я изучаю использование ORM (NHibernate в моем случае). Таким образом, я могу указать на экземпляр в SQLLite «в памяти» (а не на SQL Server), и его будет намного проще настроить / поддерживать (я надеюсь). Таким образом, мне нужно будет только смоделировать хранилище, если у меня есть требование для тестирования определенных сценариев (таких как тайм-ауты и т. Д.)

Answer 4

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

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