Ответ
В моей практике написание тестов на интеграцию с внешними сервисами — это совместная ответственность разработчиков и QA-автоматизаторов, но с четким разделением.
1. Разработчики пишут интеграционные тесты на уровне кода. Цель — проверить корректность взаимодействия нашего приложения с API внешнего сервиса (формат запроса/ответа, обработка ошибок). Мы используем моки и стабы для изоляции тестов от реального сервиса.
Пример на PHP с PHPUnit и Mockery:
// Тест для сервиса, работающего с платежным шлюзом
public function testPaymentServiceHandlesApiError(): void
{
// 1. Создаем мок HTTP-клиента (например, Guzzle)
$httpClientMock = Mockery::mock(Client::class);
// 2. Настраиваем его на возврат ошибки 500
$httpClientMock->shouldReceive('request')
->once()
->andThrow(new RequestException('Server Error', new Request('POST', 'test')));
// 3. Инжектим мок в наш сервис
$paymentService = new PaymentService($httpClientMock);
// 4. Проверяем, что сервис корректно обрабатывает исключение
$this->expectException(PaymentGatewayException::class);
$paymentService->charge(100, 'token_123');
}2. QA-автоматизаторы пишут E2E-тесты. Цель — проверить полный пользовательский сценарий, который затрагивает внешний сервис. Для этого они используют тестовые (sandbox) окружения внешних API и инструменты вроде Selenium, Cypress или Codeception.
Важное правило: Никогда не пишем интеграционные тесты, которые делают вызовы на продакшен-сервисы. Всегда используем staging-окружение, sandbox-ключи или, как в примере выше, полное мокирование.
Ответ 18+ 🔞
Слушай, а вот этот вечный спор — кто должен писать интеграционные тесты — это вообще ёперный театр. Как будто на дворе 2002-й год и мы делим территорию. На самом деле всё просто, как валенок, но с чётким разделением, чтобы не получилась пиздопроебибна, когда все всё делают и нихуя не работает.
1. Разработчики — они пишут тесты на уровне кода, внутри приложения. Их задача — проверить, что наш код правильно общается с внешним API. Не сам API, а именно наш код: правильно ли мы формируем запрос, правильно ли парсим ответ, не падаем ли в панику, если сервис нам прислал какую-то хуйню. И тут главный инструмент — моки и стабы. Мы от внешнего мира отгораживаемся, как будто он не существует. Мы просто говорим: «А сейчас пусть внешний сервис вернёт ошибку 500. Посмотрим, что наш код сделает». Идея в том, чтобы тесты были быстрыми и не зависели ни от кого.
Вот смотри, пример на PHP. Это как раз про то, как мы тестируем сервис, который дёргает платёжный шлюз:
// Тест для сервиса, работающего с платежным шлюзом
public function testPaymentServiceHandlesApiError(): void
{
// 1. Создаем мок HTTP-клиента (например, Guzzle)
$httpClientMock = Mockery::mock(Client::class);
// 2. Настраиваем его на возврат ошибки 500
$httpClientMock->shouldReceive('request')
->once()
->andThrow(new RequestException('Server Error', new Request('POST', 'test')));
// 3. Инжектим мок в наш сервис
$paymentService = new PaymentService($httpClientMock);
// 4. Проверяем, что сервис корректно обрабатывает исключение
$this->expectException(PaymentGatewayException::class);
$paymentService->charge(100, 'token_123');
}Видишь? Мы не пошли в интернет. Мы просто создали симулякр внешнего сервиса, который говорит: «Всё, я сгорел». И смотрим, не обосрётся ли наш PaymentService. Если обосрётся — значит, плохо написан. Вот и вся философия.
2. QA-автоматизаторы — их зона ответственности это E2E-тесты. Их задача — проверить весь путь: пользователь нажал кнопку «Оплатить» в интерфейсе, запрос ушёл, пришёл ответ, и пользователь увидел сообщение «Всё ок» или «Всё плохо». Тут уже используются тестовые (sandbox) окружения этих самых внешних API. Они реальные, но не боевые. Cypress, Selenium — вот это всё их инструменты.
И есть, блядь, главное правило, которое нарушать нельзя ни при каких обстоятельствах: никогда, ни за что, ни под каким предлогом не пиши интеграционные тесты, которые дёргают продакшен-сервисы. Представь, ты в тесте сделал платёж на реальный шлюз с тестовой картой, а он, сука, по какой-то причине сбоит и отправляет уведомление в финансовый отдел. Тебе потом объяснять бухгалтерам, что это не мошенничество, а просто ты, мудя, тесты писал. Используй staging, sandbox, моки — что угодно, только не прод. Иначе будет вам хиросима и нигерсраки, а не тестирование.