Пирамида тестирования: Unit → Integration → E2E?

#Пирамида

#Примеры каждого уровня

public class OrderTests
{
    [Fact]
    public void Cannot_add_item_to_paid_order()
    {
        var order = Order.Create(CustomerId.New());
        order.AddItem(ProductId.New(), 1, new Money(1000, "UZS"));
        order.MarkPaid();

        var act = () => order.AddItem(ProductId.New(), 1, new Money(500, "UZS"));

        act.Should().Throw<DomainException>().WithMessage("*оплаченный*");
    }
}

public class OrdersApiTests(ApiFactory factory) : IClassFixture<ApiFactory>
{
    [Fact]
    public async Task Post_order_returns_201_and_persists()
    {
        var client = factory.CreateClient();

        var response = await client.PostAsJsonAsync("/api/orders", new { customerId = SeedData.CustomerId, items = new[] { new { sku = "A-1", qty = 2 } } });

        response.StatusCode.Should().Be(HttpStatusCode.Created);
        await using var db = factory.CreateDbContext();
        (await db.Orders.CountAsync()).Should().Be(1);
    }
}

[Test]
public async Task Customer_can_checkout()
{
    await Page.GotoAsync("https://staging.shop.uz");
    await Page.GetByRole(AriaRole.Button, new() { Name = "В корзину" }).First.ClickAsync();
    await Page.GetByRole(AriaRole.Link, new() { Name = "Оформить заказ" }).ClickAsync();
    await Page.GetByLabel("Телефон").FillAsync("+998901234567");
    await Page.GetByRole(AriaRole.Button, new() { Name = "Подтвердить" }).ClickAsync();
    await Expect(Page.GetByText("Заказ оформлен")).ToBeVisibleAsync();
}

#Пирамида, трофей, соты

Почему в .NET-сервисах часто выбирают «трофей»:

• Много кода — «клей»: маппинг, запросы EF, конфигурация, сериализация. Unit-тест с моками всего этого проверяет лишь, что вызваны моки.
• WebApplicationFactory + Testcontainers дают интеграционный тест за секунды на реальной PostgreSQL.
• Такие тесты устойчивы к рефакторингу: проверяют поведение через публичный API, а не внутреннюю структуру.

При этом сложная доменная логика (расчёты, правила, машины состояний) — идеальный кандидат для многочисленных быстрых unit-тестов.

#Свойства хорошего теста

• Быстрый — запускается при каждом изменении.
• Изолированный / независимый — не зависит от порядка и других тестов, не делит состояние.
• Повторяемый / детерминированный — одинаковый результат всегда (никаких DateTime.Now, случайностей без seed, внешних сервисов).
• Самопроверяющийся — сам говорит pass/fail.
• Своевременный — написан вместе с кодом.
• Проверяет поведение, а не реализацию — не ломается при рефакторинге без изменения поведения.

(Первые пять — акроним FIRST.)

#Тесты в CI

Быстрые тесты — раньше, медленные — позже; падение на раннем этапе останавливает конвейер.

#Вопросы на засыпку

#Итог

Пирамида учит балансу: много быстрых тестов внизу, мало медленных наверху. В .NET-сервисах центр тяжести часто смещается к интеграционным тестам на реальной инфраструктуре в контейнерах, а unit-тесты концентрируются на сложной доменной логике. Главное — быстрая, надёжная обратная связь и тесты, проверяющие поведение, а не реализацию.