Тестирование

01Пирамида тестирования

Представьте проверку автомобиля. Каждую деталь вы проверяете на стенде (unit-тесты): их много, они быстрые и дешёвые. Системы вы проверяете вместе — двигатель с коробкой передач (интеграционные и feature-тесты): их меньше, они медленнее. А потом выезжаете на всей машине (end-to-end-тесты): их мало, они самые медленные, но ближе всего к реальности. Пирамида говорит: много unit-тестов внизу, солидный слой интеграционных тестов и тонкий слой E2E наверху. Для бэкенд-API многие команды предпочитают форму «кубка» (trophy), где самый большой слой — feature-тесты, вызывающие настоящие эндпоинты с настоящей тестовой базой, потому что именно там живёт большинство багов. В любом случае: быстрые тесты запускаются постоянно, медленные покрывают только критичные сценарии.

• Unit: одна функция или класс, без базы данных и сети.
• Feature / интеграционные: на входе HTTP-запрос, проверяются база данных и ответ.
• E2E: настоящий браузер или устройство проходит через реальный UI и API.

02PHPUnit и Pest для Laravel

Laravel поставляется с PHPUnit и Pest (более дружелюбным синтаксисом поверх PHPUnit). Feature-тесты отправляют HTTP-запросы в ваше приложение прямо в памяти и проверяют ответ, базу данных и побочные эффекты. Используйте трейт RefreshDatabase, чтобы каждый тест начинался с чистого листа; запускайте тесты на том же движке базы данных, что и в продакшене (MySQL или PostgreSQL), потому что SQLite в пограничных случаях ведёт себя иначе. Фабрики создают реалистичные модели одной строкой, со состояниями для вариаций вроде оплаченного заказа или заблокированного пользователя. Фейки Laravel подменяют внешние эффекты: Queue::fake, Mail::fake, Notification::fake, Event::fake и Http::fake позволяют проверить, что что-то было отправлено, ничего не отправляя на самом деле.

1it('lets a customer place an order', function () {
2    Queue::fake();
3    $user = User::factory()->create();
4    $product = Product::factory()->create(['price' => 2500]);
5 
6    $this->actingAs($user)
7        ->postJson('/api/v1/orders', ['items' => [['product_id' => $product->id, 'qty' => 2]]])
8        ->assertCreated()
9        ->assertJsonPath('data.total', 5000);
10 
11    $this->assertDatabaseHas('orders', ['user_id' => $user->id, 'total' => 5000]);
12    Queue::assertPushed(SendOrderConfirmation::class);
13});

03Jest, Vitest и node:test для TypeScript

В мире JavaScript Vitest — современный выбор по умолчанию для проектов на Vite и большинства новых TypeScript-проектов: быстрый, ESM-нативный и совместимый с Jest. Jest по-прежнему распространён, особенно в React Native и старых кодовых базах. В Node есть и встроенный раннер node:test, вообще без зависимостей. В NestJS используйте testing module, чтобы собрать срез приложения и подменить провайдеры фейками; для API-тестов запросы в приложение отправляет supertest. Чистую логику (ценообразование, права, правила работы с датами) тестируйте множеством маленьких unit-тестов, а эндпоинты — на настоящем PostgreSQL в Docker или Testcontainers, а не через моки ORM.

1import { describe, it, expect } from 'vitest';
2import { applyPromotion } from './pricing';
3 
4describe('applyPromotion', () => {
5  it('never discounts below zero', () => {
6    expect(applyPromotion({ subtotal: 1000 }, { type: 'fixed', amount: 1500 }).total).toBe(0);
7  });
8 
9  it('applies percentage to subtotal only, not delivery', () => {
10    const r = applyPromotion({ subtotal: 10_000, delivery: 500 }, { type: 'percent', amount: 10 });
11    expect(r.total).toBe(9_500);
12  });
13});

04Playwright для end-to-end-тестов

Playwright управляет настоящими браузерами Chromium, Firefox и WebKit. Он автоматически ждёт появления элементов, поэтому тесты гораздо менее нестабильны, чем в старых инструментах, а при падении записывает трейсы со скриншотами и сетевыми логами. Пишите E2E-тесты для нескольких сценариев, которые приносят или теряют деньги: вход, добавление в корзину и оформление заказа, ключевое действие в админке. Выбирайте элементы по роли и видимому тексту — так, как их находят пользователи, — а не по CSS-классам. Готовьте нужные каждому тесту данные через API или фикстуру, а не прокликиванием экранов настройки, и запускайте набор на окружении, похожем на staging, с заглушками внешних сервисов.

1import { test, expect } from '@playwright/test';
2 
3test('guest can check out', async ({ page }) => {
4  await page.goto('/products/sample-product');
5  await page.getByRole('button', { name: 'Add to cart' }).click();
6  await page.getByRole('link', { name: 'Cart' }).click();
7  await page.getByRole('button', { name: 'Checkout' }).click();
8  await page.getByLabel('Phone').fill('+10000000000');
9  await page.getByRole('button', { name: 'Place order' }).click();
10  await expect(page.getByRole('heading', { name: 'Thank you' })).toBeVisible();
11});

05Моки внешних сервисов и фикстуры

Ваши тесты никогда не должны обращаться к настоящему платёжному шлюзу, SMS-провайдеру или ERP. Подменяйте их на границе: оберните каждую интеграцию в собственный класс-клиент, а в тестах замените его фейком или застабьте его HTTP-вызовы (Http::fake в Laravel, MSW или nock в Node). Записывайте реалистичные ответы, включая ошибки и таймауты, в фикстуры, чтобы тестировать и пути отказа. Не мокайте то, чем владеете сами, — свои сервисы или базу данных: избыток моков даёт тесты, которые проходят, пока продакшен ломается. Фабрики собирают тестовые данные с разумными значениями по умолчанию, так что каждый тест указывает только то, что важно именно для него. Держите тесты независимыми: никакого общего состояния и обязательного порядка запуска.

06Тестирование в CI и что тестировать в первую очередь

Запускайте линтер, проверку типов и тесты на каждый pull request и блокируйте мерж, если они падают. Используйте в CI-джобе настоящую базу данных как сервис, запускайте тесты параллельно и кэшируйте зависимости, чтобы обратная связь приходила за минуты. Если E2E медленные, запускайте их на main или по ночам. В реальном продукте без тестов не гонитесь за цифрами покрытия. Начинайте там, где баг стоит дороже всего: деньги (итоги корзины, скидки, возвраты, колбэки платежей), права доступа и изоляция тенантов, а также машины состояний вроде статуса заказа. Затем добавляйте тест на каждый исправленный баг, чтобы он никогда не вернулся. Покрытие естественным образом вырастет там, где это важно.

1# .github/workflows/test.yml (excerpt)
2jobs:
3  test:
4    runs-on: ubuntu-latest
5    services:
6      postgres:
7        image: postgres:17
8        env: { POSTGRES_PASSWORD: postgres, POSTGRES_DB: app_test }
9        ports: ["5432:5432"]
10    steps:
11      - uses: actions/checkout@v4
12      - uses: pnpm/action-setup@v4
13      - uses: actions/setup-node@v4
14        with: { node-version: 24, cache: pnpm }
15      - run: pnpm install --frozen-lockfile
16      - run: pnpm typecheck && pnpm lint && pnpm test

07Быстрые изолированные тесты с базой данных

Тесты с базой данных — самые ценные тесты бэкенда и проще всего становятся медленными. Стратегии изоляции, от самой быстрой: оборачивать каждый тест в транзакцию и откатывать её (RefreshDatabase в Laravel делает это после одной миграции на запуск, а LazilyRefreshDatabase пропускает миграцию, если тест вообще не трогает базу); очищать таблицы между тестами, когда тестируемый код открывает свои транзакции или соединения; или пересоздавать базу, что медленнее всего. Запускайте параллельно: php artisan test --parallel даёт каждому процессу свою базу с суффиксом, так что тесты не сталкиваются. В Node Testcontainers поднимает настоящий PostgreSQL в Docker на каждый запуск тестов, поэтому CI и ноутбуки используют тот же движок и ту же версию, что и продакшен. Трюки для скорости: держите базу в CI на tmpfs, мигрируйте один раз и клонируйте из template database в PostgreSQL и никогда не используйте sleep в тестах.

1import { before, after } from 'node:test';
2import { execSync } from 'node:child_process';
3import { PostgreSqlContainer, type StartedPostgreSqlContainer } from '@testcontainers/postgresql';
4 
5let pg: StartedPostgreSqlContainer;
6 
7before(async () => {
8  pg = await new PostgreSqlContainer('postgres:17').start();
9  process.env.DATABASE_URL = pg.getConnectionUri();
10  execSync('npx prisma migrate deploy', { stdio: 'inherit' });
11});
12 
13after(async () => {
14  await pg.stop();
15});

08За пределами примеров: property-based и мутационное тестирование

Тесты на примерах проверяют случаи, о которых вы подумали. Property-based тестирование проверяет правила на сотнях сгенерированных входных данных: вместо «скидка 10% на 1,000 даёт 900» вы утверждаете «для любой суммы и любого процента от 0 до 100 итог никогда не бывает отрицательным и никогда не превышает сумму». Библиотеки вроде fast-check для TypeScript генерируют входные данные и при падении сжимают случай до минимального падающего примера. Это особенно хорошо для ценообразования, округления, парсинга и логики дат. Мутационное тестирование измеряет, насколько хороши ваши тесты, а не сколько кода они выполняют. Инструменты вроде Infection для PHP и Stryker для JavaScript вносят в код маленькие изменения, например превращают >= в >, и перезапускают тесты. Если тесты всё ещё проходят, мутант выжил, а значит, не хватает проверки. Покрытие говорит, что строка выполнилась; mutation score говорит, что тест заметил бы, если бы она была неправильной.

1import fc from 'fast-check';
2import { test, expect } from 'vitest';
3import { applyPromotion } from './pricing';
4 
5test('percentage promotions stay within 0 and the subtotal', () => {
6  fc.assert(
7    fc.property(
8      fc.integer({ min: 0, max: 10_000_000 }),
9      fc.integer({ min: 0, max: 100 }),
10      (subtotal, percent) => {
11        const { total } = applyPromotion({ subtotal }, { type: 'percent', amount: percent });
12        expect(total).toBeGreaterThanOrEqual(0);
13        expect(total).toBeLessThanOrEqual(subtotal);
14      },
15    ),
16  );
17});

09Архитектурные и контрактные тесты

Некоторые правила касаются структуры, а не поведения, и тесты тоже могут их охранять. Архитектурное тестирование в Pest позволяет утверждать, что контроллеры никогда не используют фасад DB, что доменный слой никогда не импортирует HTTP-классы или что отладочные функции вроде dd() не попадают в продакшен; есть и пресеты для типовых наборов правил. Между приложениями и сервисами контрактные тесты ловят самый дорогой класс багов: одна сторона меняет поле, от которого зависит другая. С consumer-driven contracts (самый известный инструмент — Pact) потребитель записывает, чего он ждёт от провайдера, а CI провайдера проверяет, что тот по-прежнему удовлетворяет каждого потребителя. Более лёгкий вариант — валидировать реальные ответы API в feature-тестах по вашей схеме OpenAPI. Оба способа гораздо быстрее и точнее полных end-to-end наборов, когда нужно доказать, что две системы всё ещё согласованы.

1// tests/ArchTest.php (Pest)
2arch()->preset()->php();       // e.g. no dd(), dump() or var_dump()
3arch()->preset()->security();  // flags eval(), md5(), sha1() and similar
4 
5arch('controllers do not query the database directly')
6    ->expect('App\Http\Controllers')
7    ->not->toUse('Illuminate\Support\Facades\DB');
8 
9arch('domain does not depend on HTTP')
10    ->expect('App\Domain')
11    ->not->toUse('Illuminate\Http');

10Тестирование времени, повторов и конкурентности

Баги, доходящие до продакшена, часто связаны со временем и повторением: подписка, истекающая на секунду раньше, задача, которая при повторе отправляет дважды, два запроса, продающие больше, чем есть на складе. Тестируйте их намеренно. Замораживайте или сдвигайте время вместо ожидания: travelTo() и travel() в Laravel, Carbon::setTestNow() или vi.useFakeTimers() и vi.setSystemTime() в Vitest. Тестируйте границы — секунду до и после дедлайна — и часовые пояса около полуночи и перехода на летнее время. Для идемпотентности запускайте одну и ту же задачу или webhook дважды и проверяйте, что эффект один. Для гонок юнит-тест с моками ничего не доказывает; отправляйте настоящие конкурентные запросы к настоящей базе, например через Promise.all в интеграционном тесте или коротким скриптом k6, и проверяйте, что инвариант — например, остаток никогда не ниже нуля — по-прежнему выполняется.

1it('expires a subscription exactly at its end time', function () {
2    $sub = Subscription::factory()->create(['ends_at' => '2026-03-01 00:00:00']);
3 
4    $this->travelTo('2026-02-28 23:59:59');
5    $this->artisan('subscriptions:expire')->assertSuccessful();
6    expect($sub->fresh()->status)->toBe(SubscriptionStatus::Active);
7 
8    $this->travelTo('2026-03-01 00:00:01');
9    $this->artisan('subscriptions:expire')->assertSuccessful();
10    expect($sub->fresh()->status)->toBe(SubscriptionStatus::Expired);
11});
12 
13it('creates one invoice even if the job runs twice', function () {
14    $order = Order::factory()->paid()->create();
15    GenerateInvoice::dispatchSync($order->id);
16    GenerateInvoice::dispatchSync($order->id);
17    expect(Invoice::where('order_id', $order->id)->count())->toBe(1);
18});