Не коректне порівняння mock.patch з responses:
Уявіть, що буде, якщо для того, аби отримати токен, вам треба спочатку дістати зі сховища (Vault) логін та пароль користувача, перевірити redis на наявність токену.
Мок може робити заглушки не тільки власних функцій, а й методів бібліотек (в данному випадку requests.get). Власне RequestsMock схоже це і робить, просто це сховано в бібліотеці. В цілому це питання смаку, але як на мене це трохи джаваскриптовий підхід — замість 4 стрічокок коду тягнути цілу бібліотеку.
mock_response = requests.Response()
mock_response._content = b'{"token": "bearer_token"}'
mock_response.status_code = 200
with mock.patch("deliveries.ByCicle.api.ByCicleAPI.get_auth_token.requests.get", retun_value=mock_response):
...
З рештою гарна стаття, щоб потикати FastAPI, для тих, хто ще цього не робив — саме те.
Тільки якщо у Вас 10к тестів на 1 ендпоїнт. Зазвичай будуть різні запити і Вам потрібно буде так само писати 10к RequestsMock чи фікстур