. 90% тестов интеграционные

- юнит тесты – мокаем все внешнее, запускаем изнутри кода
- интеграционные тесты – используем тестовое внешнее окружение (БД, API, fs, etc.), запускаем изнутри кода
- e2e тесты – запускаем приложение в отдельном процессе и тестируем вне кода самого приложения

Практически все тесты, которые я пишу интеграционные: (1) реальная сложность это чаще всего именно сочетание запросов к БД / стороннего API и бизнес-логики и только в такой связке можно проверить работоспособнсть приложения, (2) скорость их написания не меньше, чем юнит тесты, если у вас есть шаблон

Если же мне надо протестировать именно бизнес-логику (алгоритм), тогда я вынесу его в отдельную функцию, в которой не будут пробрасываться никакие внешние зависимости (чтобы ничего не надо было мокать)

. Не тестируй траспорт

Я пишу интеграционные тесты на уровне функций бизнес-логики, то есть, не включаю вызов через HTTP, MQ, TCP, etc.

Если вы хотите протестировать транспорт, тестируйте его отдельно или в рамках e2e тестов

. Тестируй фичи Условно "фича" это самая верхняя функция, которую вы вызываете из слоя транспорта. То есть, ваши тесты "имитируют вызов этого endpoint / trigger".

Тестироват глубже чаще всего не имеет смысла.

. Тестируй НЕ все

– Если это просто запрос данных, то можешь протестировать чисто то, что фильтры правильно применились, а можешь забить хрен
– Если это CRUD, который ты написал в сотый раз, можно забить хрен
– А вот если в рамках фичи ты активно меняешь какие-то данные (INSERT, UPDATE, DELETE), то ее стоит протестировать

Поэтому некоторые приложения (финансовые транзакции) я покрываю на 90%, некоторые (отдать данные фронту) на 30%

. Дели тесты на юнит и интеграционные Я делаю постфикс в название функций тестирования или файлов (например, .unit.ts, .int.ts), что позволяет мне написать отдельные конфигурации для каждого из них и запускать только те, которые нужно

. Пиши тесты рядом с кодом Только так и никак иначе. Потому что так (1) ты не протестируешь лишнее, (2) легко понять какой тест к чему относится, (3) легко переносить такую папку в сторонее место

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

. Сделать глобальную либу для тестов В такую либу я выношу: (1) подключение к БД, с созданием snapshot, (2) аутентификации, (3) seeder со всеми основными сущностями, который кладет их в БД, чтобы не приходилось делать это каждый раз заново, (4) инициатор всех нужных зависимостей (логгер, конфига, etc.)

. Не используй ООП Ну, точнее, если вы хотите протестировать отдельный метод, есть большая вероятность, что если он не статический, то вам придется создавать инстанс пропихивая множество зависимостей, которые не нужны этому методу

Если вы с этим столкнулись и хотите продолжать использовать ООП, то узнайте что такое Service Object

В ФП, ПП и ФОП такой проблемы нет (потому что каждая функция существует отдельно от другой)

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

. Используй docker-compose

Перед началом интеграционных тестов я просто из кода в global setup или же в Makefile / npm scripts, поднимаю docker-compose со всеми нужными мне БД / API, потом поднимаю миграции и фикстуры, и когда все готово уже запускаю приложение

Есть еще testcontainers, но я не увидел ниодного преимущества перед использованием чистого docker-compose

. Создавай snapshot БД

Как я делаю: создаю основную БД,, накатываю на нее миграции и фикстуры, а потом превращаю ее в template из которого каждый отдельный тест создает свою версию БД.

Это позволяет запускать интеграционные тесты все и сразу (ну, или с лимитом) и быть уверенным, что один тест не повлияет на другой.

(вторая часть ниже)

. Schema-first

Сначала опишу свою схему в виде типизации и схем API (protobuf, GQL, openapi) и только потом пиши код

В таком случае ты сможешь воспользоваться тонной разных генераторов автотестов поверх, написанной схемы. . Вместо 1000 Code Review

Вместо того, чтобы сидеть с каким-нибудь разработчиком и пытаться глубинно описать задачу (особенно джуном), я просто могу написать тесты, а он уже напишет код, который должен их пройти

Таким образом (1) я ускоряю процесс объяснения, (2) человеку намного легче понять что от него хотят, (3) пройденные тесты дают мне больше уверенности при Code Review и сокращает его время

Короче, эта техника позволяет еще удобнее менеджерить команду

. Benchmark

Есть миллиард библиотек, которые хавают подсунутый им json файл (самописный или openapi) и сами придумывают тесты, которые надо провести и отдают вам отчет.

Как пример https://github.com/nakabonne/ali , но есть и намного лучше

. Проверяй время

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

. Пример

А вот в следующем посте я уже выложу boilerplate (пока не решил на go или node.js) и расскажу как там устроено тестирование

Что по поводу testcontainers? Не вижу этого самого ожидаемого и нужного слова здесь

Не вижу никаких преимуществ перед просто запуском docker-compose даже через код, возможно, я так и не смог понять в чем там "фишка"

Раскрой тогда ?

Этот список очень похож на то, что я написал выше, но 1 важное но: там написано так, как будто он все делает "сам по себе", но на деле, при работе с testcontainers ты точно также как и с чистым docker-compose описываете все действия, которые он должен совершить

И получается "шило на мыло", но с одним важным недостатком: вам придется вводить и поддерживать конфигурацию и либы для работы с testcontainers, в тот момент когда работа с чистым docker-compose не потребует этого

А еще насчет "простоты работы с testcontainers в CI/CD" не знаю как сейчас, но раньше это было абсолютно не так, потому что при запуски из контнейра (даже dind) тебе все равно приходилось делать хак при котором testcontainers должен был получить рутовские права и проброшенный docker.sock, что вызывало кучу проблем в настройке и управлении

И да, его "параллельность" заключается в том, что он запускает контейнер под каждый тест и его окружение, но (кроме того, что это надо еще проинтегрировать с либой тестов) это жрет невероятное кол-во ресурсов (при 500+ тестов М1 просто дохнет)

Подход, описанный мной выше, не требует создания контейнера под тесты вообще, кроме интеграций и то в й1 инстанс (1 PG, 1 Redis, 1 RMQ, etc.)

С Github actions работает из коробки

Да, у меня опыт только testcontainers + Gitlab CI/CD

Так контейнер не для тестов, а для инфраструктуры, базы, редиса, rmq. В testcontainers подсовывается тот же docker compose конфиг.
Дмитрий Пацура (в YouTube искать) например также рекомендует его к использованию.

И я по-прежнему не понимаю зачем его использовать, если тоже самое можно сделать чисто с docker-compose...

У меня так и было: я использовал testcontainers, устал постоянно пытаться понять что он делает, а потом подумал: "а нахер он мне нужен?" – написал тоже самое вызывая команды docker-compose (exec("docker-compose up -d") используя между тестами и docker одинаковый env и получил тоже самое, но быстрее и более управляемее

И важно отметить: кол-во кода и конфигурации больше не стало

Короче, как я говорю: или я "не понимаю фишки", или это "прослойка над docker-compose, которая, дала чуть больше готовой конфигурации и API из-за чего разрабы, которые боятся / не понимают docker, решили ее использовать"

И да, я буду рад, если кто-то поделится конкретными примерами, где testcontainers лучше / больше, чем работ напрямую с docker-compose

Отмечу только то, что docker-compose обожает менять формат отдачи логов в каждом новом релизе, поэтому их парсить приходится каждый раз по-разному, такая проблема есть, но она возникает раз в несколько месяцев, обнаруживается на месте и фиксится за 15 минут

В остальном, я точно меньше занимаюсь дебагингом и попыткой понять: "а как это сделать на testcontainers?" – потому что точно знаю что хочу от docker-compose

+ да, я точно также делал настройку под k3s и helm-charts, которая позволяла мне запускать окружение для тестов и в кубере

С этим удобнее в ide работать, по кнопочке сразу тест запускается. А так ты во всем в целом прав )
У нас ооооч сильно замедляет процесс сам запуск через тест контейнер. Потому что jest паралелит и на каждый процесс отдельный контейнер стартует ))) в теории пофиксить можно, есть в планах так запуск дотюнить

Про работу через ide: вот пример моей конфигурации global-setup.ts, который можно прописать в jest ("globalSetup": "<rootDir>/src/tests/global-setup.ts"), поэтому я также просто делаю npm run test:int и все само стартует по тойже самой одной кнопочке)

Про замедление процесса запуска и jest праллельности: вооот я об этом и говорил выше и таких особенностей у testcontianers при интеграции с тест-фреймворком до жопы

Короче, я скоро выложу boilerplate (скорее всего под go, потому что я его уже накатал) и там все покажу

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

Опять же, вот пример настройки kafka в docker-compose и с ним я спокойно все поднимаю (может, там всего 1 инстанс, но для интеграционных тестов за глаза)