Если ваш главный этот метод формирует json не по результатам своего исполнения, а данные берет из бд, то можно ограничиться json`ом. Но вы выше написали, что доверия нет

тут не только в доверии дело, он данные не все использует

например он возвращает id митинга и все

ну да если api позволяет дернуть по условию нужному

вобщем я примерно прояснил для себя

спасиюо

итог: нужно почти все переделать )))

бггг

Я думаю, утром придут остальные. Услышим их мнения.

а что насчет плана тестирования, может тоже что посоветуете

это тоже на уровне ощунения, потомучто у нас вроде как api ендпоинты, и вроде как все абстрактно схожи, но набор тестов разный

мне кажеться это не очень хорошо

Ещё зависит, как написаны методы, тестируемы ли они. Может получиться так, что тестами можете покрыть только ваш главный класс)

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

тестировать с базой, точка. у вас же на продакшене приложение будет с базой крутиться а не с моками. А если тесты медленне - то скорее всего не в одной базе проблема… ищите узкое место. Вот пример что пишут о ускорении postgres для тестов - https://stackoverflow.com/questions/9407442/optimise-postgresql-for-fast-testing)

если нужно проверить что создалось несколько сущностей по API запросу - добавьте expect-ов / ассертов в тест кейс просто которые ходят в базу и смотрят что там создалось. Все как вам @bboollaatt выше советовал.

Если у вас код тестов и приложения в одном кодебейсе (я надеюсь так и есть из того что вы написали выше) - то можете запускать и тесты и поднимать приложение in-process и обернуть каждый test case в DB transaction, которая создается beforeEach и откатывается в afterEach (у нас такая штуковина прикручена на API проекте с JS, Express, Sequelize, Postgresql). Это может помочь вам решить вопрос с “изоляцией” тестов.

>>> и обернуть каждый test case в DB transaction, которая создается beforeEach и откатывается в afterEach (у нас такая штуковина прикручена на API проекте с JS, Express, Sequelize, Postgresql).

прикольно, не думаю что нам поможет но идея интересная

у нас mongoDb под mongoose

но mongo в кластере, а mongoose походу не умеет с транзакция работать в такой связке

в mongo я не шарю, а для тестов вам 1 монго инстанса локально в докер контейнере не хватит?

хватит так сейчас и раним

но напроде не так