Шпаргалка: как покрывать

тестами разные уровни

программы
Как ты знаешь, разные виды тестов выстраиваются в пирамиду тестирования.

Сколько проверок каждого вида нужно приложению

Универсального ответа нет: всё зависит от конкретного проекта.
Представь сервис со сложной бизнес-логикой. В коде много методов — а значит, и
юнит-тестов.

А может быть наоборот: архитектура простая, а вот API-методов много. Юнит-

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

Расчёт на примере приложения

Посмотри, как распределятся тесты по уровням пирамиды в сервисе Mesto.

Шпаргалка: как покрывать тестами разные уровни программы 1

 Приложение состоит из нескольких слоёв:

программный код с основными и вспомогательными методами;

ручки и API-методы, с которыми работает фронтенд;

UI — с ним работает пользователь через браузер.

Представь, что автотестами покрыты все три уровня. Получается, программный

код покрыт юнит-тестами, ручки — интеграционными, а UI — E2E-тестами.
Чтобы считать было проще, представь, что написали только позитивные и
негативные тесты. В реальности вариантов больше.
Например, поле ввода электронного адреса можно оставить пустым, ввести
некорректный или несуществующий e-mail. Эти три ситуации можно назвать
«негативный тест».

Ручные тесты
Сперва функциональность Mesto проходит через ручных тестировщиков. Они
готовят тест-кейсы.
Затем автоматизаторы пишут код, чтобы не проверять функциональность вручную
каждый раз.
Если подходить к тестированию так, ручных тестов будет меньше всего, ведь
новую функциональность проверяют вручную только один раз. Пока это
единственное, что можно определить точно.
Можно сказать, во время первого релиза ручных тестов столько же, сколько E2E-
тестов. Но потом их становится меньше из-за автоматизации.

E2E-тесты
Следующий уровень пирамиды — E2E-тесты. Нужно проверить такие сценарии:

1. Проверка отображения данных на главной странице без аутентификации.

2. Регистрация.

3. Аутентификация.

4. Проверка отображения данных профиля и списка фотографий.

5. Добавление фотографии.

Шпаргалка: как покрывать тестами разные уровни программы 2

 6. Удаление фотографии.

7. Лайк фотографии.

8. Изменение аватара профиля.

9. Изменение имени профиля.

Для сценариев 1 и 4 негативных проверок не будет: в них проверяют только

корректное отображение UI.

Вспомни условие: есть только позитивные и негативные проверки. Получится 16

E2E-тестов:

2 — только позитивные, потому что проверяется UI;

7 позитивных и 7 негативных — для остальных сценариев: по две проверки на

каждый.

Шпаргалка: как покрывать тестами разные уровни программы 3

 Интеграционные тесты
Посмотри на доступные ручки и типы запросов, которые им соответствуют.

Каждый API-метод — отдельный сценарий для тестирования.

Шпаргалка: как покрывать тестами разные уровни программы 4

 Для методов 3-10 нужны дополнительные негативные тесты. Они проверят, что
нельзя обработать запрос без передачи токена.

Получится 28 интеграционных тестов:

10 позитивных;

10 негативных;

8 негативных, связанных с аутентификацией.

Шпаргалка: как покрывать тестами разные уровни программы 5

 Юнит-тесты
Как ты знаешь, юнит-тесты пишут на конкретные методы.
Сейчас у тебя нет доступа к исходному коду приложения. Не получится посчитать,
сколько методов используют.

Это нормально: тестировщик не всегда видит исходный код. Чаще всего юнит-
тестами занимается тот, кто эти методы создаёт, — разработчик.

Ты не можешь посчитать, сколько понадобится юнит-тестов. Но можно

попробовать оценить на глаз.
Например, посмотри на метод POST /api/cards . Он добавляет фотографии на сайт.
Скорее всего, его написали так:

обработка входящего запроса;

валидация полей — например, для e-mail и пароля;

заполнение моделей данных, которые соответствуют ручке — например,

модель данных фотографии или пользователя;

Шпаргалка: как покрывать тестами разные уровни программы 6

 обработка ошибок;

подключение к базе данных;

добавление значения в базу;

считывание значения из базы;

отправка ответа.

Получилось восемь действий. Для каждого нужен отдельный метод. На каждый

метод разработчик напишет юнит-тест.

Если знать, сколько методов скрывается за каждой ручкой, можно прикинуть,

сколько получится юнит-тестов.
Обрати внимание, что методы обработки входящего запроса, подключения к базе
данных, добавления значения в базу, считывания значения из базы и отправки
ответа могут быть общими для нескольких ручек.
Примерное количество методов для всех ручек — 3 * 9 + 5 = 32 метода:

по 3 на каждую из 9 ручек;

5 общих методов.

Когда запускают тесты разных уровней

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

Ориентироваться на пирамиду тестирования

Пирамида показывает, что быстрых тестов нужно писать больше, чем медленных.
Например, юнит-тестов должно быть больше, чем E2E. Тогда приложение будет
хорошо покрыто тестами, а прогон не займёт много времени.
Юнит-тест обычно выполняется несколько миллисекунд или десятков
миллисекунд. В больших проектах бывают десятки тысяч юнит-тестов.

Шпаргалка: как покрывать тестами разные уровни программы 7

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

Выполнять автотесты в несколько потоков

Ещё один способ ускорить прогон — выполнять автотесты в несколько потоков.
Чем больше потоков, тем быстрее пройдут тесты.
Обрати внимание: это правило работает не всегда. Если потоков много, нужна
большая мощность серверов. Из-за этого сложнее распределить автотесты по
потокам.
Тесты могут выполняться медленнее, если у потоков общие ресурсы: например,
база с тестовыми данными. Придётся выбирать, какие проверки когда запускать.

Когда запускать тесты

Юнит-тесты быстрые, поэтому их обычно запускают после каждой сборки
приложения. Разработчик может быстро получить отчёт и продолжить писать код.
Или исправлять ошибки.
Для интеграционных и E2E-тестов есть разные варианты запуска.

✅ «По кнопке». Тесты запускаются каждый раз, когда кто-то в команде решает,
что нужен прогон. Обычно «кнопка» — это команда запуска автотестов в
инструменте CI/CD: например, Jenkins.

⏰ По расписанию. Команда решает, сколько раз в день и в какое время

запускать тесты. Например, через планировщик заданий сервера CI/CD. Чаще
всего тесты запускают раз в день — ночью. Иногда бывает два прогона: ночью и в
середине дня. Когда прогон занимает много времени, автотесты можно запускать
не каждый день. Например, если команда написала много E2E-тестов.
➡ Перед релизом. Некоторые команды запускают все автотесты прямо перед
релизом.

Обычно можно совмещать несколько вариантов, Например, автотесты

выполняются по расписанию, но их можно запустить и вручную — «по кнопке».

Шпаргалка: как покрывать тестами разные уровни программы 8

 Другие способы

Есть и другие способы сократить время прогона. Например, выполнять не все

интеграционные и E2E-тесты, а только для той функциональности, которая
изменилась.

Ты можешь комбинировать все эти способы. Например, на каждое изменение кода

выполнять тест-сьют для этой функциональности, а по ночам делать полный
прогон.

Как оценивать покрытие

Юнит-тесты
По условиям. Условие считается покрытым, если каждая ветвь решения
выполнилась.
Например, условие if (salary > salaryLimit) покрыто частично: тест проверяет
только вариант с зарплатой ниже лимита. Превышение не проверяется.
По методам. Метод считается покрытым, если он выполнился при тестировании
хотя бы один раз.

Например, метод calculateSalary вызывается в тесте. Значит, он покрыт.

Вручную считать покрытие неудобно и долго. Помогают специальные
инструменты. Один из самых популярных — плагин Jacoco.

Е2E-тесты
E2E-тесты можно оценивать по требованиям и по тест-кейсам.

По требованиям. В идеальном мире происходит так: есть набор требований и

набор тестов. С одним или несколькими пунктами требований можно сопоставить
хотя бы один из тестов.

Например, есть требование: «Нельзя зарегистрироваться дважды с одним и тем

же электронным адресом». И есть тест со сценарием — регистрируемся один раз,
регистрируемся второй раз с тем же адресом. Требование покрыто.

Процент покрытия вычисляется так:

Шпаргалка: как покрывать тестами разные уровни программы 9

 Например, есть 10 требований, а связанных тестов — 5. Процент покрытия —
50%.
По тест-кейсам. Можно сопоставить проверки с тест-кейсами и рассчитать
покрытие так:

Например, для приложения составили 1000 тест-кейсов. Тесты написали на 500 из

них. Значит, покрытие 500 / 1000 * 100 % = 50 %.
Такой подход точнее, чем способ с требованиями. В тест-кейсах указывают
конкретные параметры, поэтому связать их с тестами проще.

Тонкости. Обрати внимание, что нужно следить за актуальностью тест-кейсов — и

менять тесты, если что-то переписали.

Интеграционные
Можно оценивать покрытие по тому, сколько ручек API протестировано:

Шпаргалка: как покрывать тестами разные уровни программы 10

 Например, API состоит из 50 ручек. Интеграционные тесты написали на 25.
Значит, тестовое покрытие 25 / 50 * 100 % = 50 %.

Минусы. У этого подхода есть минус. Не учитывается, как детально

протестированы обязательные параметры ручек. А ещё непонятно, применялись
ли необязательные параметры.

Например, есть ручка GET-запроса — она ищет пользователей. Искать можно по

двум параметрам: ID пользователя и его имя.
Эти параметры необязательные. Можно не указывать их — тогда поиск идёт по
всему сразу. Ещё можно указать один или сразу оба параметра.
На ручку написали два теста — на запрос без параметров и на запрос с ID. Теста
на запрос с именем нет. Формально ручка покрыта, ведь тест на неё есть. Но
поиск по имени не проверили: он может не работать.
Если требования и тест-кейсы написаны для ручек API, можно оценивать
покрытие так же, как в случае с E2E тестами.

Шпаргалка: как покрывать тестами разные уровни программы 11