да, что бы обрабатывать ошибки
они всегда обрабатываются уровнем выше

Реальная польза от тестов? Не, не нужно

с этими тестами или бесполезные или flaky

При чем тут это?

Тестировать эндпоинты моками - лучше просто их не писать, зря потраченное время

Не совсем понял тебя. Тестировать реальными запросами эндпоинты -  это ок?

Ок

В е2е тестах ок, но тоже зависит от ситуации

Лучше сделать моку(json или объект) и отдаватб сразу как респонс и смотреть как отреагирует функция. Обычно делают success и failed case, в failed соответственно кидают new Error()

И часто команда актуализирует моки под новое поведение эндпоинта? А вы даже не узнаёте что сломалось что-то, потому что моки...

делаешь файлик с factory объектов в папке с тестами, которые инстанциируют тот же класс респонс объектов, что и в настоящем хендлере - вуаля

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

А вообще, черт знает, что тестят, поэтому сложно советовать. Если нужен условно живой АПИ для клиента, то записывать кассеты и перепроигрывать их, бонусные очки, если есть еще отдельная джоба/таска для перезаписи. Ну и можно настроить, что если апи доступно - идем туда и заодно кассеты перезаписываем, иначе, проигрываем кассеты и можем теститься оффлайн

Это удобно, да. Но не со всеми сущностями так выйдет (я не только за CRUD, есть и посложнее ;). Тем не менее вариант хорош.

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

ну boundaries должны быть, если что-то сложное - логика тестится в том проекте, что логику делает, ты уже рассчитываешь, что работаешь просто с респонсами, ведь не нужно сложную логику в двух местах тестить. А вот если там сложная логика с "если то, то делай такой запрос, иначе такой и получай вот это" то может что-то не так глобально с распределением этой самой логики и плохо размазано

ну в основном что юнит тесты, что интеграционные означают app = create_app(), test_client = app.get_test_client() и дальше реквест/респонс ассерты сильно большой разницы не вижу. Единственное, что если у вас все на сервисах и внутри хендлера только валидация входящих данных и превращение исходящего домена в жсон а посередине вызов MyCoolLogic(params).perform(), то иногда проще/быстрее юнит тестами проверить отдельно сервис, интеграционными тестами - чисто валидации. Потому что сервис ты может еще переиспользовать будешь

*quickfix

или мой мозг закостенел и я чего-то не улавливаю?

Не не, я о юнит тестах, которые через nock перехватывают vs. поднять локально апишку, чтобы контроллер реально сработал

Доброго ранку, з АПІ нової пошти ніхто не працював? Є питання з приводу зворотньої доставки і банківської картки. Можливо був в кого небудь досвід?