Как интерфейсы упрощают модульное тестирование и имитирование?

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

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

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

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

Сегодня фреймворки имитации более сложны (модификация байт-кода и т. Д.), Чем в старые времена, поэтому иногда интерфейсы или даже виртуальные методы не всегда нужны, но бессмысленные интерфейсы позволяют им.

Интерфейсы не помогут, если ваша объектная модель слишком сложна и загромождена (например, ваш интерфейс сильно зависит от других типов / интерфейсов); тогда реализовать / высмеять все это - боль.

Если у вас есть класс, у вас может быть множество зависимостей, например

• Безумные конструкторы (много аргументов, или ему нужен какой-то другой класс, которому нужен третий класс, которому нужен четвертый класс, которому требуется действительное соединение с базой данных)

• Чтобы использовать класс каким-либо образом, вы должны правильно его инициализировать (например, вы должны передать ему некоторые другие объекты, которые тоже должны быть действительными)

• У класса есть состояние. Это состояние может по какой-то причине измениться во время теста.

• Класс может иметь или использовать статические поля

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

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

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

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

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

Если вы не привязаны к конкретной реализации, вы можете переключать поведение за интерфейсом.

Если ваши классы реализуют интерфейсы, поведение можно высмеять.

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

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

При тестировании поведения, которое пересекает порт, наличие интерфейса для адаптера поможет иметь возможность внедрить другую реализацию во время тестирования (например, test double).

Например, DAO, который вызывает базу данных или веб-службу, может быть заменен реализацией, возвращающей зарезервированные данные.