Начало серии постов [Это База] положила именно тема тестирования. В связи с тем, что программистам никто не рассказал, что тесты мало того, что важные, так еще и делятся на разные типы и области тестирования.

Начнем с «Для чего это мне»: - Безболезненный рефакторинг - Быстрая проверка работоспособности фич - Помогает предотвратить каскадные ошибки - Снижает уровень связанности кода

Но это важно не только для разработчика, который должен (казалось бы) производить Качественный код, но и для руководителя: - Ранее обнаружение «багов» - Увеличение скорости разработки качественного кода в среднесрочной перспективе

Теперь поговорим предметно про пирамиду тестирования. Вы можете найти в интернете разные вариации пирамиды тестирования, но самая общая или «более правильная» основанная на моем всемирном и разно-доменном опыте она выглядит следующим образом (как показано на изображении).

Сейчас расскажу подробнее. Самые быстрые, как по запуску так и по написанию - это 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