Создаем свой проектный фреймворк автотестирования API [Часть 1/3]

[cupraer]

• Надежность обеспечивается за счет автоматической параметризации всех значений, что полностью исключает риск SQL-инъекций.

Да, защититься от SQL-ниъекций в собственных тестах — это первоочередная задача.

2026 год на дворе. Я бы на вашем месте посмотрел, что делают соседи. Property-based тесты затащили в Go (в кастрированном видек под названием fuzzying) лет 8 назад уже. А вы все фейкером данные генерируете.

[rpc1]

Для тестирования API часто требуется получать или проверять актуальные боевые данные напрямую из базы данных

Зачем для терстирования проверять боевые данные? Тестирование, по идее, должно проводиться в тестовой среде. И для E2E тестов не очень хорошо смотреть во внутренности сервиса (например в базу данных), API сервиса лучше тестировать как "черный ящик", для тестирования внутрянки используются другие типы тестов

[Jaldsky]

Спасибо за оставленный комментарий! Это первая статья, тщательного ревью, а тем более рецензирование, со стороны кого-либо не проводилось.

Зачем для терстирования проверять боевые данные

В данной формулировке я имел ввиду актуальные тестовые данные из stage-контура, ни в коем случае данные с прода.

Тестирование, по идее, должно проводиться в тестовой среде

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

И для E2E тестов не очень хорошо смотреть...

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

[rpc1]

Как правило, контрактные тесты являются более легковесными чем E2E, и построены на моках. Им важна только проверка контракта и здесь БД, тоже не нужна. Они выполняются обычно как часть CI. Я недавно активно работал на контрактном тестировании с помощью Pact.

[dyadyaSerezha]

Кроме Postman и Bruno смотрели еще что-нибудь? Как-то мало предварительный исследований на тему "что есть сейчас".

[Jaldsky]

Кроме Postman и Bruno также посмотрели в сторону Insomnia, Pororoca и Hoppscotch.

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

Если интересно почитать об альтернативах Postman и Bruno, то советую ознакомиться со статьей на habr "Отказаться от Postman, перейти на Bruno и жить счастливо"

[conopus]

В питоне с этим все хорошо: сразу после этой идет статья про Schematesis. Инструмент живёт и успешно развивается автором.