Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

«Ну, на моей машине все работает».

Я уверен, что каждый из нас слышал такую фразу от разработчика в какой-то момент своей карьеры, и все мы в ответ закатывали глаза. Очевидно же, что не работает оно на твоей машине…

Было бы хорошо применять эту же философию «это должно работать не только у меня» и к нашим тестам: каждый в команде должен иметь возможность запускать их. Автоматизация тестирования — это прежде всего быстрая обратная связь, а она возможна только тогда, когда запуск тестов быстр, плавен и не сбоит.

Также тесты должны уметь запускаться по требованию, без необходимости ждать, пока кто-то подготовит машину, настроит необходимые тестовые данные, и так далее. Неважно, означает ли «по требованию» один раз за спринт или десять раз в день – тесты должны быть готовы к запуску.

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

Так мы избегаем необходимости делать кучу работы позже, когда уже написали десятки или даже сотни тестов, чтобы автоматизировать их запуск и сделать этот процесс таким быстрым, плавным и бесшовным, каким его хотелось бы видеть.

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

Напишите пару небольших, но значимых тестов

Они не обязательно должны быть самыми важными тестами. Вовсе нет. Но поскольку нет смысла писать бесполезные тесты, выберите что-то, что должно «просто работать». Для UI-тестов это может быть сценарий входа в ваше приложение. Для API-теста выберите запрос, который получает данные из бэкенд-системы – желательно что-то, что непременно в ней будет. Получите бонусные баллы, если API-вызов требует аутентификации. Для модульных тестов напишите тест для значимой части поведения вашего кода. Нет необходимости тестировать геттеры и сеттеры.

Убедитесь, что эти тесты надежно запускаются на вашем локальном компьютере, запустив их несколько раз через командную строку. Почему через командную строку? Потому что именно так ваши тесты будут запускаться в CI на следующем этапе, так что лучше сразу научиться делать это правильно.

Ваши тесты должны вести себя одинаково при каждом запуске и выдавать одинаковые результаты. Сам код пока не обязательно должен быть красивым — до этого мы еще дойдем.

Чему это вас научит: написанию тестов, работе с библиотеками для тестирования.

Поместите ваши тесты в систему контроля версий

Большая часть кода (включая тесты) требует совместной работы, и единственный надежный и масштабируемый способ сотрудничества по коду — использовать систему контроля версий. Поэтому логичным следующим шагом будет поместить ваши тесты под контроль версий. Обязательно исключите/игнорируйте те части вашего кода, которые не должны попадать под контроль версий, включая:

• скомпилированный код и другие сгенерированные артефакты
• отчеты о тестировании
• учетные данные и другие секреты.

Что касается учетных данных и секретов, обращайтесь с ними так же, как и ваша команда разработчиков. Обычно это означает использование какого-либо хранилища ключей или секретов и/или использование переменных окружения.

Чему это вас научит: работе с системами контроля версий, обращению с секретами в вашем коде.

Добавьте прогон тестов в CI-пайплайн

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

В любом случае убедитесь, что ваши тесты запускаются каждый раз, когда инициируется сборка CI. Это может быть триггер по времени («запускать тесты каждую ночь в 23:00»), триггер по событию («запускать тесты каждый раз, когда кто-то делает коммит в ветку / создает pull request») или и то, и другое. Главное, чтобы тесты запускались как минимум раз в день — это уже хорошо. Частый запуск тестов нужен для быстрого получения обратной связи по двум аспектам:

• состоянию приложения, которое вы проверяете с помощью этих тестов, и
• надежности самих тестов.

Второй пункт очень важен — нам нужно с самого начала начать повышать доверие к нашим тестам, а единственный способ это сделать — часто запускать их на машине другого человека, то есть через CI.

Чему это вас научит: созданию/редактированию CI-пайплайнов, настройке и работе с CI-агентами.

Параллельный прогон тестов

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

Если ваш набор содержит много end-to-end тестов, время прогона быстро возрастет. Запуск тестов параллельно — отличный способ с этим справиться, и это гораздо проще сделать, пока набор тестов ещё в зачаточном состоянии. Некоторые фреймворки поддерживают параллельное выполнение тестов «из коробки», для других потребуется немного больше усилий. Однако внедрение параллельности на раннем этапе избавит вас от множества проблем в будущем, так что сейчас самое время заняться этим.

Чему это вас научит: запуску тестов параллельно, работе с конфликтами конкуренции.

Следующие шаги

Только после того, как мы написали первые тесты, поместили их под контроль версий, автоматизировали их запуск с помощью CI и убедились, что тесты могут работать параллельно без проблем, можно переходить к другим задачам, включая:

• улучшение читабельности и поддерживаемости существующего кода тестов
• добавление отчетов и уведомлений по результатам тестирования
• обеспечение возможности запуска тестов в нескольких средах (если необходимо)

Конечно, большую часть времени (фактически, почти всё время) вы будете добавлять новые тесты в ваш набор. Но, пожалуйста, сделайте себе одолжение и начинайте это делать только после завершения предыдущих шагов. Позже вы (и я ;) ) скажете себе спасибо за правильный старт и подготовку к успеху.

P.S.: хотите попрактиковаться в том, о чем я писал в этом посте? Я создал этот открытый проект специально для вас.

Обсудить в форуме