Мечта любого технического директора, инженера или владельца продукта – добиться полного покрытия кода автоматизированными тестами. Автотесты работают без участия человека, и их можно выполнять как часть процесса сборки и деплоя приложения. Они могут включать в себя модульные тесты (unit tests), тестирование API, тестирование функционала для конечных пользователей – все, что последовательно проверяет кодовую базу без участия человека.

Сложность создания и поддержки автоматизированных тестов состоит в том, что для правильного выполнения бизнес-логики требуется разработка соответствующих сценариев и тестовых данных. Например, вам нужно протестировать удаление учетной записи пользователя. Часть теста заключается в том, чтобы выполнить удаление учетной записи и убедиться, что она удалилась. Ничего сложного? Так и есть, но, чтобы иметь возможность удалить учетную запись, сперва ее нужно создать. Вот такой порочный круг – добро пожаловать в тестирование.

Заметки с полей

Не ведитесь на количество

Глен Мартин (Glen Martin), который в свое время был менеджером по продукту спецификации Java Enterprise, преподал мне ценный урок о важности качества, а не количества тестов. Он проиллюстрировал это утверждение, спросив меня, какой автомобиль я выберу: тот, который прошел 10 000 тестов, или тот, который прошел только один тест? Естественно, как молодой наивный инженер, я выбрал первый вариант. И попал в классическую ловушку, предположив, что количество равняется качеству. Глен ответил, что автомобиль, прошедший 10 000 тестов, не прошел тест запуска двигателя, а единственным тестом, который прошел другой автомобиль, был именно этот тест. Простой и очевидный пример, который я помню спустя почти 25 лет.

Покрытие кода – важная метрика, которую следует учитывать при оценке качества тестов. Она показывает, какая часть исходного кода фактически выполняется при прохождении теста. Но не весь код одинаков – какие-то фрагменты кода гораздо важнее других, особенно те, которые выполняются чаще или предоставляют критически важные сервисы.

Поэтому при оценке покрытия кода необходимо определить наиболее важные компоненты. Для них необходимо обеспечить максимальное тестирование. 100 % покрытия кода достичь почти невозможно; хорошим результатом можно считать 50–70 %.

Автоматизация исключает из ручного тестирования повторяющиеся действия, помогая избежать утомления, при котором пропускаются важные шаги. Разработка системы автотестов требует большого количества работы; кроме того, ее необходимо поддерживать в актуальном состоянии. Добавление каждой новой функции может привести к невыполнению тестов, которые приходится обновлять.

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

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