Тестирование — продвинутый разбор

«Test double» — общий зонтичный термин Жерара Мезароса для любых объектов, заменяющих реальные коллабораторы в тесте. Различие между подтипами — не педантизм: путаница mock'а со stub'ом приводит к тестам, которые ломаются при безобидном рефакторинге и не ловят настоящие баги. В отличие от популярного «всё это моки», точная таксономия даёт язык для проектирования тестов и обсуждения их в ревью.

Дано: NotificationDispatcher с зависимостями — UserRepository (читает получателей), RateLimiter (ограничивает частоту), MailGateway (отправляет почту), AuditLogger (пишет аудит). Каждую зависимость подменим уместным типом дубля.

final class NotificationDispatcher
{
    public function __construct(
        private UserRepository $users,
        private RateLimiter     $limiter,
        private MailGateway     $mail,
        private AuditLogger     $audit,
    ) {}

    public function send(string $campaignId): int
    {
        $users = $this->users->subscribed();
        $sent = 0;
        foreach ($users as $user) {
            if (!$this->limiter->allow($user->id)) continue;
            $this->mail->send($user->email, $campaignId);
            $this->audit->record('sent', $user->id);
            $sent++;
        }
        return $sent;
    }
}

// Тест: «при двух подписчиках, оба прошли лимит — обе почты ушли»
public function test_sends_email_to_each_allowed_user(): void
{
    // Stub — отвечает на запрос подписчиков:
    $users = $this->createStub(UserRepository::class);
    $users->method('subscribed')->willReturn([
        new User(1, 'a@example.com'),
        new User(2, 'b@example.com'),
    ]);

    // Stub с фиксированным «да» от лимитера:
    $limiter = $this->createStub(RateLimiter::class);
    $limiter->method('allow')->willReturn(true);

    // Mock — фиксируем ожидание именно двух вызовов с конкретными аргументами:
    $mail = $this->createMock(MailGateway::class);
    $mail->expects($this->exactly(2))
         ->method('send')
         ->willReturnCallback(function (string $to, string $campaign) {
             $this->assertContains($to, ['a@example.com', 'b@example.com']);
             $this->assertSame('spring-sale', $campaign);
         });

    // Dummy — нам безразлично, что аудит-логгер делает в этом тесте:
    $audit = $this->createStub(AuditLogger::class);

    $dispatcher = new NotificationDispatcher($users, $limiter, $mail, $audit);
    $sent = $dispatcher->send('spring-sale');

    $this->assertSame(2, $sent);
}

Когда уместен fake вместо mock? Если бы AuditLogger хранил факт записи и далее использовался в проверках, fake (например, in-memory имплементация) был бы предпочтительнее: тест проверял бы итоговое состояние (state-based), а не цепочку вызовов (interaction-based). Это устойчивее к рефакторингу.

Тест — код, который читают чаще, чем пишут: при поломке его открывают в спешке, чтобы понять, что именно сломалось. Структура теста определяет, насколько быстро это понимание достигается. Хороший тест читается как параграф: задана ситуация → выполнено действие → проверен результат. Плохой — читается как клубок настроек.

Популярный принцип «один assert на тест» нередко уродует тест: вместо одного логичного действия — десять методов, повторяющих setup. Точнее формулировать: одно действие и столько assert'ов, сколько нужно для полной проверки исхода этого действия. Если действий два — разделите на два теста.

// Anti-pattern: act-блок выполняет два независимых действия
public function test_user_lifecycle(): void
{
    $user = User::factory()->create();
    $user->activate();             // действие 1
    $this->assertTrue($user->isActive());

    $user->block('spam');          // действие 2
    $this->assertSame('spam', $user->block_reason);
}

// Два теста, по одному действию каждый
public function test_activate_marks_user_active(): void
{
    $user = User::factory()->create();

    $user->activate();

    $this->assertTrue($user->isActive());
    $this->assertNotNull($user->activated_at);
}

public function test_block_stores_reason(): void
{
    $user = User::factory()->active()->create();

    $user->block('spam');

    $this->assertFalse($user->isActive());
    $this->assertSame('spam', $user->block_reason);
}

Тест-сюта — это система: соотношение её слоёв определяет общую скорость, надёжность и стоимость поддержки. Слишком много медленных интеграционных тестов — CI занимает 40 минут. Слишком мало — зелёная сюта не ловит баги интеграции. Архитектурные модели (пирамида, трофей, соты) — способ обсудить эти соотношения с командой.

Между двумя сервисами договорённость о формате запросов и ответов называется контрактом. Consumer-driven contract testing (Pact) переворачивает подход: потребитель пишет ожидаемые взаимодействия, эти ожидания передаются провайдеру, провайдер при сборке проверяет, что его реализация удовлетворяет контракту. Преимущество перед E2E: не нужно поднимать всю инфраструктуру; падение чётко локализовано в одну сторону взаимодействия.

// Псевдокод consumer-side test (Pact PHP):
$builder = new InteractionBuilder($config);
$builder
    ->given('user 42 exists')
    ->uponReceiving('a request for user 42')
    ->with(['method' => 'GET', 'path' => '/users/42'])
    ->willRespondWith([
        'status' => 200,
        'body'   => ['id' => 42, 'email' => 'a@example.com'],
    ]);

// Pact записывает контракт в pact.json и публикует в Pact Broker.
// На стороне провайдера CI поднимает API и проигрывает все контракты.

База данных — почти всегда самый медленный коллаборатор. Правильно выбранная стратегия изоляции состояния между тестами определяет, сколько секунд (или минут) занимает прогон всей сюты. Laravel предлагает несколько готовых трейтов; каждый имеет своё применение, и неправильный выбор бьёт по производительности или корректности.

Тестов становится больше каждый месяц; время «зелёного PR» растёт линейно от их числа, если ничего не предпринимать. Параллельное исполнение — первое и самое дешёвое средство удержать feedback-петлю короткой. Laravel 8+ поставляет встроенную интеграцию с ParaTest через php artisan test --parallel; Pest имеет собственный параллельный режим. Главное в обоих — изоляция: процессы не должны мешать друг другу через общие БД, файлы, кеш и порты.

// tests/CreatesApplication.php — настройка изоляции
use Illuminate\Support\Facades\ParallelTesting;
use Illuminate\Support\Facades\Redis;

trait CreatesApplication
{
    public function createApplication(): \Illuminate\Foundation\Application
    {
        $app = require __DIR__ . '/../bootstrap/app.php';
        $app->make(\Illuminate\Contracts\Console\Kernel::class)->bootstrap();

        ParallelTesting::setUpProcess(function (int $token) {
            // Каждый процесс получает собственный Redis DB index.
            config(['database.redis.cache.database' => $token]);
            config(['database.redis.default.database' => $token]);
        });

        ParallelTesting::setUpTestDatabase(function (string $database, int $token) {
            // Сюда можно положить общие seed'ы, нужные каждому процессу.
        });

        ParallelTesting::tearDownProcess(function (int $token) {
            Redis::connection()->flushdb();
        });

        return $app;
    }
}

Запуск: php artisan test --parallel --processes=8 --recreate-databases. Флаг --recreate-databases пересоздаёт все шарды; на CI — обязателен (предыдущая сюита могла оставить БД в неконсистентном состоянии).

Источники недетерминизма ломают тесты предсказуемо — не сегодня, так через неделю. Главные виновники: текущее время, случайные числа, асинхронные задачи. Каждый из них — контролируемая сущность в Laravel; правильное использование инструментов превращает потенциально флакающий тест в воспроизводимый.

// Тестируем, что подписка истечёт через 30 дней и тогда отправится напоминание.
public function test_renewal_reminder_sent_one_day_before_expiry(): void
{
    Queue::fake();

    // Замораживаем время на «сегодня в 10:00 UTC».
    $this->travelTo(now()->setTime(10, 0));

    $subscription = Subscription::factory()->create([
        'expires_at' => now()->addDays(30),
    ]);

    // Перемещаемся в момент за день до истечения.
    $this->travel(29)->days();

    (new ScheduleRenewalReminders())->__invoke();

    Queue::assertPushed(SendRenewalReminder::class,
        fn (SendRenewalReminder $job) => $job->subscriptionId === $subscription->id);
}

Тест полностью детерминирован: now() зафиксирован, очередь — in-memory, никакой реальной отправки. То же поведение можно проверить и через Queue::sync + Mail::fake(), если важна проверка финального письма, а не задачи в очереди.

Любое взаимодействие с внешним сервисом — источник недетерминизма, нестабильности и затрат: API может быть медленным, недоступным, лимитированным по запросам или платным. Laravel'овский Http-клиент предоставляет встроенный fake, который покрывает 90% случаев; для оставшихся применяются recorded-сценарии и WireMock-подобные сервисы.

public function test_charge_retries_on_502_and_succeeds_on_third_attempt(): void
{
    Http::preventStrayRequests();
    Http::fake([
        'api.stripe.com/*' => Http::sequence()
            ->push(['error' => 'bad_gateway'], 502)
            ->push(['error' => 'bad_gateway'], 502)
            ->push(['id' => 'ch_123', 'amount' => 1000], 200),
    ]);

    $gateway = app(StripeGateway::class);
    $result  = $gateway->charge(1000, 'USD', 'idem_42');

    $this->assertSame('ch_123', $result->id);

    Http::assertSentCount(3);
    Http::assertSent(fn (Request $req) =>
        $req->header('Idempotency-Key')[0] === 'idem_42');
}

Тест декларирует ожидаемое поведение (две неудачи и успех на третьей попытке), проверяет результат и подтверждает, что idempotency-key передан во всех попытках — это критично для финансовых операций.

Coverage отвечает на вопрос «исполнялась ли строка кода во время тестов» — это слабое утверждение. Mutation testing отвечает на сильнее: «обнаружит ли сюта, если этот код изменится?». Инструмент (для PHP — Infection) делает множество мелких изменений в исходниках (мутаций) и прогоняет тесты на каждой. Если все тесты проходят на мутации — значит, сюта эту строку не реально проверяет; такая мутация называется survived. Если хотя бы один тест падает — мутация killed. Отношение убитых к общему числу — mutation score.

• Арифметика: + ↔ -, * ↔ /;
• Сравнения: > ↔ >=, == ↔ !=, < ↔ <=;
• Возвращаемые значения: return $x → return null, return true → return false;
• Условия циклов: foreach ($items) → foreach ([]);
• Логические операторы: && ↔ ||, ! убирается;
• Удаление вызовов методов с типом возврата void.

// composer require --dev infection/infection

// infection.json5
{
    "$schema": "vendor/infection/infection/resources/schema.json",
    "source": {
        "directories": ["app"],
        "excludes":    ["app/Http/Controllers", "app/Console"]
    },
    "timeout": 10,
    "logs": {
        "text":    "build/infection.log",
        "summary": "build/infection-summary.log"
    },
    "mutators": {
        "@default": true,
        "@function_signature": false
    }
}

# Прогон. --threads берёт N процессов; --min-msi — минимальный mutation score
vendor/bin/infection --threads=8 --min-msi=80 --min-covered-msi=90

Параметры --min-msi и --min-covered-msi ставят пороги: первый — общий mutation score, второй — mutation score только по покрытым строкам. На CI Infection валит сборку, если пороги не достигнуты — это превращает качество тестов в измеряемую величину, как и обычное coverage.

Типичный профиль: Infection прогоняет в 30-100 раз дольше обычной сюты (на каждой мутации — полный тест-ран). Не запускайте на каждом PR — запускайте ночью или вручную перед релизом.

Coverage — популярная, но опасно неточная метрика. Менеджмент часто требует «80% coverage», команда подгоняет цифру тестами, которые ничего не проверяют. Чтобы метрика была полезной, важно понимать: что именно она измеряет, чем отличаются её разновидности и почему 100% line coverage не равно «всё протестировано».

// phpunit.xml — включаем coverage, добавляем фильтр
<coverage>
    <include>
        <directory suffix=".php">app</directory>
    </include>
    <exclude>
        <directory>app/Console</directory>
        <file>app/Providers/RouteServiceProvider.php</file>
    </exclude>
</coverage>

# XDebug медленный, для скорости используйте PCOV:
pecl install pcov
php -d pcov.enabled=1 vendor/bin/phpunit --coverage-html=build/coverage --coverage-clover=build/clover.xml

Coverage пригоден как индикатор «вот эта папка ни разу не тронута», не как мера качества. Сочетайте с mutation testing для адекватной картины.

Snapshot-тестирование — запись «снимка» вывода (JSON, HTML, текст) при первом прогоне и сравнение с ним на последующих. Цель — быстро ловить непредвиденные изменения в выводе сложной структуры (рендеринг шаблона, сериализация модели в JSON, ответ API). Используется парами: snapshot фиксирует факт, code review подтверждает легитимность обновлённого snapshot'а.

// composer require --dev spatie/phpunit-snapshot-assertions

use Spatie\Snapshots\MatchesSnapshots;

final class ProductApiTest extends TestCase
{
    use MatchesSnapshots;

    public function test_product_show_response_shape(): void
    {
        $product = Product::factory()->create([
            'id'         => 42,
            'name'       => 'Test SKU',
            'created_at' => '2026-01-01 00:00:00',
        ]);

        $response = $this->getJson("/api/products/{$product->id}");

        $this->assertMatchesJsonSnapshot($response->json());
    }
}

Первый прогон создаёт файл __snapshots__/ProductApiTest__test_product_show_response_shape.json. Последующие сравнивают — любое отклонение валит тест. Если изменение легитимно (новое поле в ответе) — обновить snapshot командой: vendor/bin/phpunit -d --update-snapshots и зафиксировать в коммите.

Дано: модуль InvoiceGenerator, написанный одним статическим методом, который читает заказ из БД, считает налоги по сложной таблице, генерирует PDF, отправляет письмо, пишет аудит-лог. Покрыто двумя feature-тестами, дающими 22% line coverage. Любая правка ломает один из них непредсказуемо. Задача — пошагово привести к тестируемому виду.

// Исходник: всё в одном методе, ничего не тестируется отдельно.
final class InvoiceGenerator
{
    public static function generate(int $orderId): string
    {
        $order = DB::table('orders')->find($orderId);
        $tax = 0;
        if ($order->country === 'KZ') $tax = $order->total * 0.12;
        elseif ($order->country === 'DE') $tax = $order->total * 0.19;
        // ... ещё 18 стран ...

        $pdf = (new Dompdf())->loadHtml(view('invoices.show', compact('order', 'tax'))->render());
        $pdf->render();
        $path = storage_path("invoices/{$orderId}.pdf");
        file_put_contents($path, $pdf->output());

        Mail::to($order->email)->send(new InvoiceMail($path));
        DB::table('audit')->insert(['action' => 'invoice', 'order_id' => $orderId]);

        return $path;
    }
}

• До: 2 медленных feature-теста, 22% line coverage, любая правка — рулетка;
• После: 24 unit-теста (мгновенные), 3 feature-теста (smoke), 86% line coverage, 78% mutation score;
• Время рефакторинга — ~4-6 часов; экономия времени поддержки — десятки часов в год.