Кто пишет тесты на внешние сервисы?

Кто и как пишет тесты на внешние сервисы в PHP-разработке

В современной PHP-разработке тестирование взаимодействия с внешними сервисами (API сторонних систем, платежные шлюзы, сервисы нотификаций, базы данных, кэш-хранилища и т.д.) — это сложная, но решаемая задача. Ответ зависит от контекста, но в целом ответственность распределяется между разработчиками, QA-инженерами и DevOps/инженерами по надежности, причем каждый вносит свой вклад на разных уровнях тестирования.

Основные подходы к тестированию внешних сервисов

1. Модульные и интеграционные тесты (ответственность разработчика)

Разработчик обязан покрыть код, взаимодействующий с внешними сервисами, тестами. Для этого используются:

Моки (mocks) и стабы (stubs) — заменяют реальный сервис в тестах:

// Пример с PHPUnit и мок-объектом
$externalServiceMock = $this->createMock(ExternalService::class);
$externalServiceMock->method('fetchData')
    ->willReturn(['id' => 123, 'status' => 'success']);

$processor = new DataProcessor($externalServiceMock);
$result = $processor->process();
$this->assertEquals('processed', $result);

Фейковые (fake) реализации — упрощенные, но рабочие версии сервисов для тестов:

class FakePaymentGateway implements PaymentGatewayInterface {
    private $payments = [];
    
    public function charge(float $amount): string {
        $transactionId = uniqid('fake_');
        $this->payments[$transactionId] = $amount;
        return $transactionId;
    }
}

2. Контрактное тестирование (разработчики + DevOps)

Для микросервисной архитектуры применяется consumer-driven contract testing (например, с Pact). Разработчики пишут тесты, которые проверяют:

• Форматы запросов и ответов
• Коды HTTP
• Структуры данных

// Пример контракта с Pact
$consumer = new Consumer('OrderService');
$provider = new Provider('PaymentService');

$contract = $consumer->hasPactWith($provider);
$contract->uponReceiving('a charge request')
    ->with($request)
    ->willRespondWith($response);

3. Тесты API (разработчики + QA)

Для тестирования реальных внешних API используются:

Специализированные инструменты:

• Postman/Newman для коллекций запросов
• Behat для поведения на PHP
• Codeception для API-тестирования

// Пример API-теста с Codeception
$I = new ApiTester($scenario);
$I->sendPOST('/api/webhook', ['event' => 'payment.succeeded']);
$I->seeResponseCodeIs(200);
$I->seeResponseContainsJson(['status' => 'processed']);

4. E2E и приемочные тесты (преимущественно QA)

QA-инженеры создают сценарии, которые проходят через всю систему, включая внешние сервисы:

• Реальные интеграции в staging-среде
• Тестовые данные в sandbox-режимах сервисов
• Проверка бизнес-логики целиком

Ключевые практики и принципы

Изоляция тестовой среды:

• Использование Docker-контейнеров для запуска зависимостей
• Тестовые аккаунты и sandbox-режимы внешних сервисов
• Базы данных в памяти (SQLite) для интеграционных тестов

Управление конфигурацией:

// Конфигурация для разных сред
return [
    'external_api' => [
        'base_url' => env('EXTERNAL_API_URL', 'https://sandbox.api.com'),
        'timeout' => env('EXTERNAL_API_TIMEOUT', 30),
        'retry_attempts' => 3
    ]
];

Обработка ошибок и таймаутов:

class ExternalServiceClient {
    public function requestWithRetry(string $method, int $maxRetries = 3) {
        for ($attempt = 1; $attempt <= $maxRetries; $attempt++) {
            try {
                return $this->makeRequest($method);
            } catch (ConnectException $e) {
                if ($attempt === $maxRetries) {
                    throw new ServiceUnavailableException();
                }
                sleep(2 ** $attempt); // Экспоненциальная задержка
            }
        }
    }
}

Распределение ответственности

1. Разработчики пишут:

   • Модульные тесты с моками
   • Интеграционные тесты с фейками
   • Контрактные тесты
   • Базовые API-тесты

2. QA-инженеры создают:

   • E2E сценарии
   • Нагрузочные тесты интеграций
   • Тесты на устойчивость к сбоям

3. DevOps/SRE обеспечивают:

   • Тестовые среды, близкие к продакшену
   • Мониторинг интеграций
   • Симуляторы внешних сервисов

Золотые правила

• Никогда не тестировать напрямую с продакшен-сервисами — используйте sandbox
• Тестируйте не только "счастливый путь", но и ошибки, таймауты, невалидные ответы
• Изолируйте тесты от реальных внешних зависимостей на нижних уровнях
• Верифицируйте интеграции на staging-среде перед выпуском
• Внедряйте circuit breakers и тестируйте их работу

Итог: В современной PHP-разработке тестирование внешних сервисов — это коллективная ответственность, где разработчики закладывают основу через модульное тестирование, QA проверяет интеграции целиком, а DevOps обеспечивает инфраструктуру для реалистичного тестирования. Наиболее эффективный подход — комбинация изолированных юнит-тестов, интеграционных тестов с фейками и периодического E2E-тестирования в контролируемой среде.