Каковы правильные способы издевательства - фальшивка, имитация или заглушка?
Не используйте моки. ¹ Моки - это глупо. ²
Проще сказать, чем сделать. Моки повсюду. Невозможно протестировать без моков.
Какие есть альтернативы? Почему макеты не подходят для всех? Как использовать другие тестовые двойники?
Какие у вас есть фиктивные альтернативы?
Существуют только издевательства. Мока достаточно.
Давайте посмотрим на следующий пример кода.
Что не так с примером? engine. Не следует над этим смеяться. В тесте не используется engine. Mock добавляет больше шаблонов и не служит цели.
Давайте посмотрим на другой пример.
Это проверяет поведение notificationService. Сервисный макет используется для поведенческих тестов. Как бы вы проверили состояние notificationService? Допустим, вам нужно проверить количество отправленных писем об обновлении. Вы не можете этого сделать с текущей реализацией.
Как бы вы имитировали сервис, предназначенный только для производства? Давайте протестируем загрузку файла S3. S3 доступен только в более высоких средах. С моками в том виде, в каком мы их знаем, это невозможно.
Как мы можем улучшить предыдущие примеры?
Используйте манекен. При проверке уровня топлива вас не заботит engine. Тем не менее, вам необходимо передать аргумент в конструктор.
Давайте проверять оценки, но не заботимся о студенте. Вот как можно проверить оценки фиктивного учащегося.
Используйте mocks для проверки поведения. Используйте шпионов для проверки состояния. Для предыдущего примера вам понадобится notificationServiceSpy. Spy позволяет тестировать как состояние, так и взаимодействие.
Хотите протестировать метод класса? Заглушите класс.
Заглушки необходимы для интеграционных тестов. Интеграционные тесты с локально недоступным сервисом. Вы бы создали StubS3UploadClient, чтобы протестировать или саботировать загрузку. Заглушки могут передать логику недоступной службы на ваш локальный компьютер.
Зачем вам нужны манекены? Манекены создают краткие, хорошо написанные и простые тесты. Манекен прошел как имитация, оставляя место для ошибки. Используемый манекен правильно передает свое предназначение. Используйте манекены для создания эффективных тестов.
Зачем нужны заглушки? Моки - это не заглушки. Заглушки проверяют как взаимодействие, так и поведение. Заготовки делают ваши тесты полноценными.
Заглушки дают вам контроль над сторонними сервисами. Допустим, вы не хотите спамить песочницу обработчика заказов. Вы можете создать обработчик заказов на заглушки. Заглушки упрощают тестирование, расширяют контроль и делают то, что имитировать не могут.
Подделки лучше махинаций
Отслеживайте количество моков. Моков не должно быть много. Тест с большим количеством моков - это красный флаг.
Большинство разработчиков бездумно используют макеты. Они используют mocks, чтобы соответствовать контракту всего класса. Издевательства помогают, но не злоупотребляйте ими.
Вы перестаете использовать имитаторы? Нет. Обратите внимание на то, что вы используете. При необходимости используйте макеты.
Если у вас есть mocks, возвращающие mocks, возвращающие mocks, ваш тест полностью связан. Вы не можете ничего изменить, не провалив тест! Я не хочу идти на такой компромисс »- Кент Бек
Возврат моков - это красный флаг. Почему? Вы создаете интеграционный тест в модульном тесте. Пересмотрите свою стратегию тестирования, удалите фиктивные элементы, создайте хороший интеграционный тест.
Сцепление плохо для рефакторов. Ваша работа по рефакторингу удваивается. Вам нужно изменить реализацию и тесты. Многие mocks вызывают сильную связь. Тесная связь приводит к длинным рефакторам.
Вы не должны бросать насмешки. Моки делают нашу жизнь проще. Вы должны следить за количеством моков. Тест с большим количеством моков - нарушение единой ответственности.
Как тест с большим количеством имитаторов нарушает единую ответственность? У вашего класса много соавторов. Класс с множеством зависимостей - это божественный класс.
Егору Бугаенко не нравится идея издевательств. Он заявляет, что фейки лучше, чем издевательства. Подделки в его реализации поставляются вместе с производственным кодом.
Мне не нравится эта идея. Вы создаете другую абстракцию. Абстракции другим разработчикам необходимо расшифровать. Пользовательские подделки, которые, скорее всего, не будут задокументированы. Вы потратите драгоценное время на тестирование, а не на разработку.
Поддельные объекты действительно имеют рабочие реализации. Подделки сокращаются, что делает их непригодными для производства. База данных в памяти - хороший пример. - Месарош
Тестовые двойники полезны, но могут выйти из-под контроля. Используйте подделки, а не издевательства. Имейте по одной авторитетной фальшивой реализации каждой услуги. - "источник"
Не бросайте Fakes. Подделки - это модернизированные манекены. Вы можете использовать методы, которые вас интересуют, и не заботиться обо всем остальном. Прекрасным примером является тестирование HttpServletRequest.
Допустим, LoginServlet использует только getAttributeNames и getAttribute. Без фейков было бы много насмешек. Еще один атрибут карты - еще один макет. Фейки создают краткие тесты, избавляют от насмешек и используют только то, что им нужно.
Не злоупотребляйте издевательствами. Есть еще 4 альтернативы. Манекены, подделки, заглушки и шпионы. Познакомьтесь поближе с тестовыми двойниками. Повышайте осведомленность о тестовых двойниках. Создавайте краткие тесты.
Проверьте, что подходит лучше всего. Подделку нельзя воткнуть, если пустышка нужна. Изучите варианты использования тестовых двойников. Общее практическое правило - избегайте тесной связи между тестируемой и тестируемой системой.
