Изучаем юнит-тестирование с NUnit на C#

1. Дублёр (Substitute, Double) – в контексте юнит-тестирования это компонент системы, который заменяет другой компонент во время тестирования. Дублёр может быть настроен для имитации работы оригинального компонента или для изоляции теста от внешних зависимостей.

2. Подделка (Mock) – это вид дублёра, который обычно создаётся с использованием специальных библиотек (например, Moq или NSubstitute). Подделки обеспечивают контроль над взаимодействием между тестовым кодом и его зависимостями, позволяя моделировать любой результат для любого вызова.

3. Пустышка (Stub) – это ещё один вид дублёра, который отличается от мока тем, что он всегда возвращает одно и то же значение при каждом запросе, независимо от контекста. Пустышки используются, когда нужно моделировать определённый результат без необходимости в контроле всех возможных взаимодействий.

4. Заглушка (Stub or Fake) – термин может использоваться как синоним "пустышки", но иногда его употребляют для описания более простого дублёра, который лишь примиряет интерфейс, не реализуя полную функциональность.

5. Подставка (Shim) – это дублёр, который используется для внедрения зависимостей в ситуациях, когда вам нужно изменить поведение оригинального компонента на продакш-среду без изменений в самом коде. Подставки часто используются для изоляции тестов друг от друга.

Чтобы вручную прописывать дублёры, вам нужно:

• Определить интерфейс или класс, который вы хотите заменить.
• Создать новый класс, который будет реализовывать тот же интерфейс или наследуется от того класса.
• Реализовать логику, соответствующую потребностям вашего теста.

Пример использования NSubstitute для создания дублёра:

var someService = Substitute.For<ISomeService>();
someService.SomeMethod().Returns(new SomeResult());

В этом примере ISomeService - это интерфейс, а SomeService - дублёр, который будет использоваться в тесте.

Что касается подходов к юнит-тестированию:

1. Детройтская школа (Detroit School) – сосредотачивается на фактах и редко использует моки, акцент делает на простых тестах, которые быстро проходят и легко поддерживаются.

2. Лондонская школа (London School) – предполагает более сложные тесты, которые могут включать моки и проверку множества различных сценариев. Этот подход часто использует "красный-зелёный-рефакторинг".

Разработка через тестирование (TDD) – это методология, где тесты пишутся до кода, который они тестят. Это приводит к более устойчивому и лучше тестируемому коду. Процесс "красный-зелёный-рефакторинг":

1. Красный (Red) – писать тесты, которые сразу же проваляют (красные), пока все тесты отражают требования к функциональности.
2. Зелёный (Green) – затем писать минимально функциональный код, который делает тесты проходимыми (зелёные).
3. Рефакторинг (Refactor) – после того как все тесты проходят, улучшать и оптимизировать код, сохраняя тестовую покрытую.

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