В модульном тестировании зачем мне дважды создавать репозиторий?

На днях я немного читал о модульном тестировании и видел несколько примеров, когда люди создают интерфейс репозитория (т.е. IExampleRepository), а затем создают реальный репозиторий ( public class ExampleRepository : IExampleRepository) и репозиторий, который будет использоваться для модульного тестирования ( FakeExampleRepository : IExampleRepository).

В IExampleRepositoryних были реализованы те же методы, что и в ExampleRepository, но с разными запросами Linq.

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

Одной из целей модульного тестирования является тестирование только одной вещи за раз, то есть одного класса и метода. Если сам репозиторий не тестируется, вы обычно каким-то образом его смоделируете, чтобы просто проверить логику в вашем методе / классе.

Тем не менее, вам также нужно тестировать с «реальным» хранилищем *, но обычно это делается в интеграционном / системном тесте.

* _{очевидно реальный, как в репо, настроенном на тестирование, возможно, не на производственной БД.}

Я согласен с двумя ответами от JK. и Ян Худек - они дают действительно хорошую информацию. Но я думал, что добавлю немного.

Ваш первый вопрос («Что именно является целью здесь?») Важен. В случае, если вы описываете, реальная цель состоит в том, чтобы протестировать классы, использующие IExampleRepositoryинтерфейс, а не тестировать реализации репозитория. Создание FakeExampleRepositoryпозволяет вам тестировать эти клиентские классы, не беспокоясь о деталях реального класса репозитория.

Это особенно верно, если объект, который вы пытаетесь настроить, затрудняет тестирование (например, доступ к файловой системе, вызов веб-службы или связь с базой данных). Используя интерфейсы (и другие подобные методы), вы сохраняете низкий уровень связи. Следовательно, класс Xдолжен знать только об интерфейсе и не должен знать о деталях реализации. Цель состоит в том, чтобы убедиться, что класс Xделает правильные вещи.

Насмешка (или заглушка, подделка ... есть нюансы) - это мощный инструмент для модульного тестирования и TDD. Но может быть боль вручную создавать и поддерживать эти реализации. Таким образом, большинство языков теперь имеют библиотеки-насмешки, чтобы помочь. Поскольку вы используете C #, я бы порекомендовал Moq, потому что он простой и очень мощный. Затем вы можете протестировать интерфейс без накопления лишнего кода для ложных реализаций.

Какова именно цель здесь?

Изоляция.

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

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

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

Взгляните на изолирующие фреймворки (такие как Moq, как предложено @Allan), чтобы иметь возможность быстро сгенерировать эти подделки для настройки условий тестирования и использовать их для подтверждения.

Есть три причины, по которым вы можете захотеть предоставить фиктивный экземпляр для модульного тестирования:

1. Вы хотите ограничить область действия теста, чтобы на тест не влияли ошибки в depndee, возможно, потому что он еще не завершен или нестабилен, или вы не хотите, чтобы ошибки в чьем-либо другом влияли на ваши тесты.
2. Зависимого сложно настроить. Например, уровень доступа к данным часто макетируется, потому что реальный требует настройки тестовой базы данных. Вам все еще нужно протестировать реальный уровень доступа к данным, но вы можете ограничить дорогостоящие настройки при отладке других вещей.
3. Чтобы проверить, что зависимый класс правильно реагирует на различные виды ошибок, вы предоставляете фиктивную версию, которая возвращает всевозможные неправильные ответы. Потому что многие виды отказов довольно сложно воспроизвести, но все же следует их протестировать.