👨‍💻 TDD в больших проектах

Все слышали мантру: «пиши тесты сначала, код потом». Звучит разумно. Но когда проект уже большой, то TDD может занять куда больше сил.

Казалось бы, вот простая задача: добавить поле DeliveryComment к заказу. Бизнес просит, задача на час.

Давайте по TDD — сначала тест:

[Fact]
public void CreateOrder_WithDeliveryComment_ShouldPersistComment()
{
    var service = new OrderService(...); // 6 зависимостей
    var request = new OrderRequest { DeliveryComment = "Позвонить за 10 минут" };
    var result = service.CreateOrder(request);
    Assert.Equal("Позвонить за 10 минут", result.DeliveryComment);
}

Чтобы написать этот тест, вам нужно: поднять моки для всех зависимостей OrderService, разобраться, как устроен OrderRequest, понять, где вообще маппинг в entity. А сама фича — это три строки кода:

// OrderRequest.cs
public string? DeliveryComment { get; set; }

// OrderEntity.cs
public string? DeliveryComment { get; set; }

// OrderService.cs
entity.DeliveryComment = request.DeliveryComment;

Три строки. Тест к ним — тридцать. И это тест, который проверяет, что присвоение работает. То есть тест на то, что C# умеет присваивать строки.

Для сложной бизнес-логики с граничными случаями он работает отлично. Но когда вы добавляете поле к DTO или прокидываете значение через три слоя — писать тест до кода означает тратить время команды на церемонию ради церемонии.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view