Ведущий архитектор решений в Билайн · 01.09 · ред.
[Это База] Пирамида тестирования
Начало серии постов [Это База] положила именно тема тестирования. В связи с тем, что программистам никто не рассказал, что тесты мало того, что важные, так еще и делятся на разные типы и области тестирования.
Начнем с «Для чего это мне»: - Безболезненный рефакторинг - Быстрая проверка работоспособности фич - Помогает предотвратить каскадные ошибки - Снижает уровень связанности кода
Но это важно не только для разработчика, который должен (казалось бы) производить Качественный код, но и для руководителя: - Ранее обнаружение «багов» - Увеличение скорости разработки качественного кода в среднесрочной перспективе
Теперь поговорим предметно про пирамиду тестирования. Вы можете найти в интернете разные вариации пирамиды тестирования, но самая общая или «более правильная» основанная на моем всемирном и разно-доменном опыте она выглядит следующим образом (как показано на изображении).
Сейчас расскажу подробнее. Самые быстрые, как по запуску так и по написанию - это Unit tests, они супер легковесные, проверяют твою функцию или компонент моментально с десятками (если того требует) возможными входящими данными, и показывают возможные ошибки, и ответы твоих функций в зависимости от входящих параметров. Мало кто задумывается о том как правильно писать Unit tests.
Каждый Unit test обязан следовать следующему правилу AAA (triple-A), и тут как раз отлично происходит отсылка к пирамиде бейсбольных лиг (используется часто и в классификации игр, фильмов и т.п)
(A)rrange (A)ct (A)ssert
Таким образом, первые пару строчек Unit test должен иметь для подготовки данных. Следующие 1-2 строки для выполнения действия, такого как запуск функции, запуск рендера компонента. И последняя строчка для проверки полученных значений с ожидаемыми.
В связи с этим, из опыта, получается не очевидный момент, который каждый программист должен знать - нельзя Unit tests называть отстраненно или общими словами такими как «проверка функции», «проверка всего», «проверка удачи» или «проверка провала» и тому подобное.
Вот пример лучшего названия Unit test: “Withdrawal > When balance is insufficient > Should Throw Insufficient Funds Exception” “Calculate Total > When No Items In Cart > Should Return Zero” Таким образом мы мало того, что имеем иерархическую структуру так называемых describe (как групп Unit tests) так и наборы Unit tests с конкретным описанием того, что проверяем. И если данный тест упадет то значит только в этом тесте проблема.
Получается «неписаное» (потому, что вас никто не ограничивает), но очень полезное правило
1 unit test === 1 expect
И если так нельзя или не получается - значит код написан не «правильно» и не корректно и требует рефакторинга и разбиения (потому, что у нас есть такие практики как SOLID, DRY, KISS и т.п)
Разобрались с Unit tests, поговорим про Local integration tests.
Данные тесты, как и External integration tests, очень похожи на Unit tests, только их суть и цель совершенно другая, как и подготовка.
Проверяем в Local integration tests следующее: - Взаимодействие между модулями - Работа с базами данных (отдельные действия как работа с пользователем, с той или иной таблицей и т.п) - Конфигурация приложения - Работа с файловой системой - Проверка валидаторов и их преобразований
Остальные правила, по сути, такие же как и в случае с Unit tests.
Точно так же обсудим и External integration tests
Мы должны проверять там: - Интеграцию с облачными базами данных - Проверять API взаимодействия - Управление очередями и событиями - Безопасность - Автоматическое масштабирование
И самое не понятное это E2E UI tests. Я понимаю, что это «под»-категория интеграционных тестов, не зря же их полное название End-to-end integration tests? И зачастую это именно UI тесты.
Это самые медленные тесты, самые!медленные!тесты!
Запомните, их нужно писать в самую последнюю очередь.
Есть разные типы таких тестов: - BDD - TDD - Snapshot regression - Performance UI
Единственное, что стоит еще подчеркнуть это соотношение количества тестов, как понять, сколько тестов нужно писать:
70% Unit tests 20% Integration tests 10% UI tests
· 03.09
Интересный пост, спасибо. Правда программисты знают о важности тестов, другое дело лень их писать, хотя это проходит после того как просят внести изменения в объемный сервис к которому уже давно не притрагивался - начинаешь ценить тесты.
ответить
· 01.09
Сталкивалась с проектами, где пирамида тестирования была перевернута. Интересные кейсы, конечно
ответить
еще контент автора
еще контент автора
Ведущий архитектор решений в Билайн · 01.09 · ред.
войдите, чтобы увидеть
и подписаться на интересных профи