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

Почему старая архитектура была нетестируемой

Нетестируемость из вступительной истории была структурной. OrderService имел compile-time зависимости от PostgresOrderRepository, StripeClient и SendGridClient. Чтобы создать OrderService в тесте, нужно было либо предоставить реальную инфраструктуру, либо замокировать эти классы с помощью мок-фреймворка. Оба варианта несут издержки:

Реальная инфраструктура в тестах требует настройки окружения (Docker Compose, внешние аккаунты, доступ в сеть), медленная (секунды на тест, минуты на набор) и нестабильная (внешние сервисы падают, контейнеры таймаутят, rate limits срабатывают).

Мок-фреймворки требуют от теста знания внутренних деталей реализации OrderService — какие методы он вызывает у каких зависимостей, в каком порядке, с какими аргументами. Когда OrderService рефакторится (например, извлекается доменный метод), моки ломаются, даже если поведение не изменилось. Тесты становятся хрупким бременем сопровождения вместо надёжных страховочных сеток.

Обе проблемы разделяют одну первопричину: OrderService имеет прямые source-code зависимости от инфраструктурных классов. Тест не может изолировать доменную логику от этих зависимостей без предоставления их или замены структурно идентичными копиями (моками).

Hexagonal architecture устраняет первопричину. Domain не имеет source-code зависимостей от инфраструктурных классов — он зависит только от собственных интерфейсов портов. Случайно создать экземпляр PostgresOrderRepository внутри domain невозможно, потому что domain не импортирует его. Единственный способ удовлетворить secondary port — предоставить реализацию, которой может быть быстрый in-memory fake.

Вызов через primary port с тест-драйвером

Тест-драйвер является driving adapter (урок 02). Он вызывает primary port напрямую, как это делает HTTP-контроллер. HTTP не задействован — ни сервер, ни парсинг запросов, ни форматирование ответов.

// domain/ports/OrderConfirmationPort.ts
interface OrderConfirmationPort {
  confirmOrder(orderId: string, approverId: string): Promise<ConfirmationResult>;
}

// Тест: вызов через primary port
describe('Order confirmation use case', () => {
  let useCase: OrderConfirmationPort;
  let orderRepo: InMemoryOrderRepository;
  let paymentGateway: FakePaymentGateway;
  let emailNotifier: FakeEmailNotifier;

  beforeEach(() => {
    orderRepo = new InMemoryOrderRepository();
    paymentGateway = new FakePaymentGateway();
    emailNotifier = new FakeEmailNotifier();

    // Собираем use case с fake driven adapters
    useCase = new OrderConfirmationUseCase(orderRepo, paymentGateway, emailNotifier);
  });

  it('подтверждает pending-заказ и снимает оплату с клиента', async () => {
    // Arrange: помещаем pending-заказ в fake-репозиторий
    const order = Order.pending({ id: 'order-1', customerId: 'cust-42', amount: Money.of(500, 'USD') });
    await orderRepo.save(order);

    // Act: вызываем через primary port
    const result = await useCase.confirmOrder('order-1', 'approver-99');

    // Assert: доменный результат
    expect(result.success).toBe(true);
    expect(paymentGateway.chargesIssued).toHaveLength(1);
    expect(paymentGateway.chargesIssued[0].amount).toEqual(Money.of(500, 'USD'));
    expect(emailNotifier.sentMessages).toHaveLength(1);
  });

  it('отклоняет подтверждение при наличии просроченных счетов', async () => {
    const order = Order.pending({ id: 'order-2', customerId: 'cust-42', amount: Money.of(200, 'USD') });
    order.markInvoiceOverdue('inv-7');
    await orderRepo.save(order);

    const result = await useCase.confirmOrder('order-2', 'approver-99');

    expect(result.success).toBe(false);
    expect(result.reason).toBe('overdue-invoice');
    expect(paymentGateway.chargesIssued).toHaveLength(0);
  });
});

Никакого Docker Compose. Никакого Stripe-аккаунта. Никакого SendGrid-sandbox. Каждый тест выполняется за миллисекунды. Тестовый набор может содержать сотни тестов и завершаться менее чем за две секунды.

In-memory fakes на secondary ports

Ключевой элемент — in-memory fake: простая, быстрая реализация secondary port, хранящая состояние в памяти. Это не mock (который записывает ожидания вызовов); это реальная реализация, просто использующая память вместо сети или диска.

// Реализует secondary port: IOrderRepository
class InMemoryOrderRepository implements IOrderRepository {
  private store = new Map<string, Order>();

  async findById(id: string): Promise<Order | null> {
    return this.store.get(id) ?? null;
  }

  async save(order: Order): Promise<void> {
    this.store.set(order.id, order);
  }

  async findByCustomerId(customerId: string): Promise<Order[]> {
    return [...this.store.values()].filter(o => o.customerId === customerId);
  }
}

// Реализует secondary port: IPaymentGateway
class FakePaymentGateway implements IPaymentGateway {
  public chargesIssued: Array<{ customerId: string; amount: Money }> = [];
  public shouldFail = false;

  async charge(customerId: CustomerId, amount: Money): Promise<ChargeResult> {
    if (this.shouldFail) return ChargeResult.failure('card-declined');
    this.chargesIssued.push({ customerId: customerId.value, amount });
    return ChargeResult.success(`charge-${Date.now()}`);
  }

  async refund(chargeId: ChargeId, amount: Money): Promise<RefundResult> {
    return RefundResult.success();
  }
}

Fakes реализуют интерфейс secondary port в точности — тот же интерфейс, что реализуют production-адаптеры Postgres и Stripe. Domain use case не может отличить их во время компиляции. В runtime тест подставляет fake; production подключает реальный адаптер. Один и тот же use case выполняется в обоих контекстах без модификации.

Пирамида тестов, которую используют hexagonal-команды

Структурное разделение domain от адаптеров создаёт естественную трёхуровневую пирамиду тестов:

Уровень 1 — Domain-тесты (много, миллисекунды): вызов через primary port с тест-драйвером и fake driven adapters. Тестирует каждое бизнес-правило, каждый инвариант, каждый граничный случай в domain. Эти тесты не имеют инфраструктурных зависимостей — они выполняются везде, мгновенно. Это основная часть тестового набора: каждая комбинация состояния заказа, логики согласования, правила биллинга и условия ошибки. На B2B-платформе это сотни тестов, покрывающих полную логику подтверждения, выставления счетов и согласования биллинга.

Уровень 2 — Тесты адаптеров (меньше, секунды): тестирование каждого адаптера изолированно против контракта его порта. Тест PostgreSQL-репозитория запускает реальную базу данных, сохраняет и извлекает доменные объекты, проверяет правильность маппинга. Тест Stripe-адаптера (против тестового API Stripe) проверяет маппинг charge/refund. Тест HTTP-контроллера проверяет, что поля HTTP-запроса корректно парсятся в параметры порта и результаты порта корректно сериализуются в HTTP-ответы. Эти тесты проверяют, что адаптер корректно реализует порт — они не пере-тестируют доменную логику.

Уровень 3 — End-to-end тесты (очень мало, секунды-минуты): запуск полного приложения со всеми реальными адаптерами. Отправка реальных HTTP-запросов. Проверка интеграции всего стека. Эти тесты дороги — оставляй их только для критических happy path.

Уровень 1: Domain-тесты    ████████████████████████████████████  (сотни)
Уровень 2: Тесты адаптеров ██████████                            (десятки)
Уровень 3: E2E-тесты       ██                                    (единицы)

Исходная проблема B2B-платформы — 72% номинального покрытия через медленные интеграционные тесты — была симптомом полного отсутствия тестов Уровня 1. Всё было Уровнем 3. Hexagonal architecture инвертирует это: тесты Уровня 1 дёшевы в написании, потому что domain полностью доступен через primary port без инфраструктуры.

Тесты адаптеров: тестирование границы снаружи

Тесты адаптеров структурно независимы от domain-тестов. Они тестируют другой вопрос: «Правильно ли этот адаптер реализует контракт порта?»

// Тест адаптера: PostgresOrderRepository реализует IOrderRepository
describe('PostgresOrderRepository', () => {
  let db: Pool; // Реальное PostgreSQL-соединение
  let repo: PostgresOrderRepository;

  beforeAll(async () => {
    db = await createTestDatabase();
    repo = new PostgresOrderRepository(db);
  });

  it('сохраняет и извлекает заказ по id', async () => {
    const order = Order.pending({ id: 'test-1', customerId: 'c-1', amount: Money.of(100, 'USD') });
    await repo.save(order);
    const retrieved = await repo.findById('test-1');
    expect(retrieved).toEqual(order);
  });

  it('возвращает null для несуществующего заказа', async () => {
    const result = await repo.findById('no-such-id');
    expect(result).toBeNull();
  });
});

Эти тесты запускают реальную базу данных. Они медленнее domain-тестов. Но покрывают одно, чего domain-тесты не могут: корректный маппинг между доменными объектами и строками базы данных (имена столбцов, типы, обработка NULL, сериализация). Domain-тест с fake-репозиторием никогда не обнаружит баг маппинга столбца. Тест адаптера поймает его точно, не тестируя при этом доменную логику.