В интернете есть немало статей и докладов, описывающих различные подходы к тестированию приложений: от TDD до "тестируем пользователями в проде".
Какой из них лучший? И вообще, стоит ли выбирать какой-то один подход и всегда его придерживаться? На эти вопросы нет однозначного ответа. Каждый должен сам для себя выбрать то, что поможет ему решать его задачи наиболее эффективно.
Я, как и бльшинство моих коллег, при тестировании бэкенд-приложений придерживаемся следующих правил:
1) по-максимуму автоматизировать тестирование. Стремиться сделать так, чтобы руками приходилось тестировать как можно меньше. Для этого подходят: юнит-тесты, интеграционные тесты, автотесты;
2) на этапе разработки приложения стремиться к получению большей выгоды от написания тестов. Выгодность тестов определяется следующими признаками:
- 1 интеграционный тест выгоднее 1 юнит-теста. Если на какой-то функционал не написан интеграционный тест, то выгоднее будет написать 1 интеграционный тест, который проверит 1 положительный сценарий на всех уровнях: от эндпоинта с провекой аутентификации до получения данных из базы данных. Такой тест будет проще написать, чем 10 юнит-тестов на разные компоненты приложения, проверяющих тот же сценарий. Интеграционный тест проверит взаимодействие всех компонентов нового функционала и даст большее тестовое покрытие, чем юнит-тесты,
- 10 юнит-тестов выгоднее 10 интеграционных тестов. Если у нас уже написан 1 интеграционный тест и дальше стоит выбор: написать ещё 10 интеграционных тестов на разные сценарии или 10 юнит-тестов, проверяющих то же самое, то лучше написать 10 юнит-тестов. Это позволит существенно ускорить время написания и выполнения тестов, не потеряв при этом в качестве тествого покрытия. При наличии сложной бизнес-логики можно написать на неё юнит-тесты, проверяющие как можно больше сценариев её работы. Если бизнес-логика не представляется сложной, то можно ограничиться одним интеграционным тестом,
- отдельно необходимо протестировать работу рукописных (кастомных) запросов к базе данных и адаптеров с самописным парсингом результатов запросов. Для этого в тест-контейнере поднимается база данных и проверяется правильность работы с ней репозиториев и адаптеров к репозиториям,
- если есть требования к валидации входящих параметров запросов, то для такой валидации необходимо написать юнит-тесты;
3) при исправлении ошибок в приложении необходимо писать тесты, воспроизводящие ошибки (падающий, если такая ошибка присутствует);
4) при поднятии контекста приложения в тестах, нужно чтобы контекст поднимался только 1 раз для всех тестов. Контекст приложения может подниматься довольно долго. Чем меньше раз он поднимается (в идеале - 1 раз перед запуском всех тестов), тем меньше времени займёт выполнение тестов;
5) каждый тест должен сам для себя готовить тестовые данные и удалять их после выполнения теста. Если не соблюдать это правило, то:
- рано или поздно тесты начнут мешать друг другу своими данными,
- общие данные, которыми может наполняться тестовая база данных перед запуском всех тестов, рано или поздно перестанут соответствовать продуктивным данным или изменениям в схеме базы данных и нужно будет потратить много сил и времени на то, чтобы исправить их и тесты, которые их используют.