День 1486. #Testing Ода Юнит-Тестам: в Защиту Пирамиды Тестирования. Начало В 2014 году Дэвид Хайнемайер Ханссон взорвал мир разработки, когда на RailsConf заявил, что «TDD — это смерть». Многие последовали за ним, разделив разработчиков на два лагеря. Сегодня модульные тесты теряют своё значение в пользу интеграционных тестов, и пирамида тестирования превратилась в ромб, где главную роль теперь играют интеграционные тесты. Каждый начинает с того, что делает всё возможное. Пробует, ошибается, пробует снова, пока кто-то не разорвёт этот круг и не предложит другой путь. Путь к набору тестов с минимальными затратами на обслуживание. Следующие вопросы могут помочь избежать ощущения необходимости в Тестовом Ромбе вместо Пирамиды: - Эта проблема вызвана юнит-тестами или тем, как я их пишу? - Применяю ли я интеграционные тесты к компонентам, которые в нём нуждаются? - Я что-то неправильно понял, что привело меня к одним и тем же утверждениям в нескольких местах? - Улучшаю ли я свой дизайн с помощью тестов или просто тестирую существующий дизайн? Исторически интеграционное тестирование было этапом совместного тестирования разных модулей, которые разрабатывались изолированно, часто несколькими командами. Сегодня они применяются к единицам кода, разработанным одной командой, как будто каждый файл кода является границей системы. Это стирает границы между модульными и интеграционными тестами. Это восприятие является неверным. Мы должны определить чёткие границы, которые дадут представление о роли системы и о том, как она взаимодействует с другими. Это похоже на гексагональную архитектуру (или архитектуру Порты-Адаптеры), в которой система имеет две стороны: внутреннюю и внешнюю, и нам нужно соединить эти две стороны через чётко определённые границы. Именно такое представление проясняет связь между модульными и интеграционными тестами. Модульные тесты отвечают за проверку границы изнутри, а интеграционные - снаружи. Т.е. интеграционные тесты обеспечивают правильное поведение адаптеров, шлюзов и клиентов, которые отвечают за отношения с другими единицами разработки (API, плагины, базы данных и модули). Поведенческое тестирование Что означает модуль в модульных тестах? Это единица поведения. Т.е. тест не должен быть сосредоточен на одном файле, объекте или функции. Почему сложно писать модульные тесты, ориентированные на поведение? Общая проблема со многими типами тестирования возникает из-за тесной связи между структурой ПО и тестами. Это происходит, когда разработчик упускает из виду цель тестирования и подходит к ней в чистом виде (иногда называемом белым ящиком). Тестирование методом «белого ящика» означает тестирование с учётом внутреннего дизайна, чтобы гарантировать правильную работу системы. Это очень распространено в модульных тестах. Проблема в том, что тесты имеют тенденцию становиться слишком гранулированными, и в итоге вы получаете огромное количество тестов, которые трудно поддерживать из-за их тесной связи с базовой структурой. Частично недовольство модульными тестами связано с этим фактом. Интеграционные тесты, более удалённые от дизайна, как правило, менее подвержены влиянию рефакторинга, чем модульные. Является ли это преимуществом интеграционных тестов или проблемой, вызванной подходом к тестированию методом белого ящика? Что, если бы мы тестировали методом чёрного ящика? Распространённым заблуждением является мнение, что тестирование чёрных ящиков можно применять только к внешним границам системы. Это не так. Наша система имеет множество границ. У каждого модуля есть свои границы, и его можно протестировать с помощью поведенческого подхода. Окончание следует… Источник: https://www.infoq.com/articles/unit-tests-testing-pyramid/