в ИТ база в любом случае должна быть, настоящая или in-memory. Мокать конекторы к базе с помощью мокито в ИТ не следует. То есть в ИТ не надо лезть внутрь приложения и что-то там менять.

Тут речь идет про интеграционное тестирование же

обязательно проверять на живой базе

юнит тесты так и реализоываны интеграционных нет у меня нет проблемы это реализовать, есть проблема выбрать что конкретно я тестирую, если интеграционные тесты то что подавать на вход, что ждать на выход, вот у меня есть 4 слоя

на контроллере два варианта, ошибка есть, ошибки нет
в сервисе ещё две проверки на бизнес логику
в репозитории ещё пара проверок перед доступом к данным

и того 2*2*2 уже 8 кейсов и их количество растёт экпоненциально, нужно выбирать тлько часть

я и есть разраб)

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

я ж говорю, не думай по ветвлениям в коде. У тебя на вход приходит какой-то джсон. В нем какие-то данные. Сделай перечисление всех разных вариантов наборов данных с приоритезацией по бизнесу.

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

спасибо, записал, это близко к тому что я ищу)

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

я разрабатываю и систему и тесты, qa есть но он не занимается автотестами

слишком сложно
разраб не умеет писать тесты или что?

самое время начать ему заниматься автотестами)

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

это моя задача)

берете тз - делаете тесты по тз

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

формализованного тз нет, максимум это дерево функций

дизайн тестов и "накодить" вещи малосвязанные. Для того что бы подставить разные данные кодить ничего не надо. А проблема видимо только в этом. Есть кто-то со стороны бизнеса? ПО, аналитик? Он может помочь с кейсами.

было бы лучше, но сейчас это невозможно