
## Introduction

Testing is not separate from clean code. Code that is hard to test is usually tightly coupled or unclear.

## 1) Design for testability

### Inject dependencies

```csharp
public class TrialService(TimeProvider clock)
{
    public bool IsTrialExpired(User user)
        => clock.GetUtcNow() > user.TrialEndDate;
}
```

Avoid direct static/global dependencies such as `DateTime.Now` in business logic.

## 2) Follow AAA structure

- Arrange
- Act
- Assert

```csharp
[Fact]
public void CalculateTotal_WithDiscount_ReturnsDiscountedPrice()
{
    // Arrange
    var items = new List<OrderItem>
    {
        new("Widget", 100m, 2),
        new("Gadget", 50m, 1)
    };
    var calculator = new PriceCalculator(0.10m);

    // Act
    decimal total = calculator.CalculateTotal(items);

    // Assert
    total.Should().Be(225m);
}
```

## 3) Use descriptive test names

Pattern: `MethodName_Condition_ExpectedResult`

Examples:

- `GetByIdAsync_OrderNotFound_ReturnsNull`
- `Validate_EmptyCustomerId_ThrowsValidationException`
- `PlaceOrderAsync_ValidRequest_SavesAndNotifies`

## 4) Test behavior, not implementation details

Avoid brittle tests tied to internal method calls.

- Good: verify output, state change, emitted event, HTTP response
- Bad: over-verifying private interaction chains

## 5) Keep tests deterministic

Sources of flakiness:

- current time
- random values
- network dependencies
- shared mutable state

Use fakes/stubs/test containers and isolate external systems.

## 6) Fast feedback strategy

A practical test pyramid for C# backends:

- many unit tests (fast)
- fewer integration tests (database/API boundaries)
- minimal end-to-end tests (critical user flows)

## Summary

Testability is a design outcome. If dependencies are explicit and methods are cohesive, your tests become simpler, faster, and more valuable.


Write cleaner C# code by designing for testability and focusing tests on behavior using AAA and descriptive naming.

xUnit

C# Clean Code