TDD in .NET: Anti-Patterns & When NOT to Use TDD

// Bad: Test obsession
[Fact]
public void Age_Getter_ReturnsAge()
{
    var person = new Person { Age = 30 };
    Assert.Equal(30, person.Age); // What's this testing?
}

[Fact]
public void Name_Getter_ReturnsName()
{
    var person = new Person { Name = "John" };
    Assert.Equal("John", person.Name); // And this?
}

// This bloats your test suite without adding value.
      

// Better: Focus on behavior
[Fact]
public void IsAgeValid_WhenAgeIsNegative_ReturnsFalse()
{
    var person = new Person();
    var result = person.IsAgeValid(-5);
    Assert.False(result);
}

[Fact]
public void IsAgeValid_WhenAgeIsOver150_ReturnsFalse()
{
    var person = new Person();
    var result = person.IsAgeValid(200);
    Assert.False(result);
}
      

// Bad: Over-mocking
[Fact]
public void ProcessOrder_WithMockedEverything()
{
    var mockValidator = new Mock<IOrderValidator>();
    var mockLogger = new Mock<ILogger>();
    var mockRepository = new Mock<IOrderRepository>();
    var mockEmailService = new Mock<IEmailService>();
    var mockNotificationService = new Mock<INotificationService>();
    
    // 50 lines of setup...
    
    var service = new OrderProcessor(mockValidator.Object, mockLogger.Object, 
        mockRepository.Object, mockEmailService.Object, mockNotificationService.Object);
    
    // 10 lines of test...
    
    // What are we actually testing?
}
      

// Better: Mock only what's external
[Fact]
public void ProcessOrder_SendsEmailAfterSuccess()
{
    var mockEmailService = new Mock<IEmailService>();
    var validator = new OrderValidator(); // Real - catches issues in validation logic
    var repository = new InMemoryOrderRepository(); // Real - tests the contract between layers
    
    var service = new OrderProcessor(validator, repository, mockEmailService.Object);
    
    service.ProcessOrder(new Order { Id = 1, Amount = 100 });
    
    mockEmailService.Verify(x => x.SendConfirmation(It.IsAny<string>()), Times.Once);
}
      

// Bad: No refactoring (Real-world: Discount calculation)
[Fact]
public void CalculateDiscount_StandardCustomer_5Percent()
{
    var calculator = new DiscountCalculator();
    var discount = calculator.Calculate(100, CustomerType.Standard);
    Assert.Equal(5, discount); // 5% of 100
}

[Fact]
public void CalculateDiscount_PremiumCustomer_10Percent()
{
    var calculator = new DiscountCalculator();
    var discount = calculator.Calculate(100, CustomerType.Premium);
    Assert.Equal(10, discount);
}

[Fact]
public void CalculateDiscount_VIPCustomer_15Percent()
{
    var calculator = new DiscountCalculator();
    var discount = calculator.Calculate(100, CustomerType.VIP);
    Assert.Equal(15, discount);
}

// Minimal code to pass tests, but impossible to read
public class DiscountCalculator
{
    public decimal Calculate(decimal amount, CustomerType type)
    {
        decimal d = 0;
        if (type == CustomerType.Standard) { d = amount * 0.05m; }
        if (type == CustomerType.Premium) { d = amount * 0.1m; }
        if (type == CustomerType.VIP) { d = amount * 0.15m; }
        return d;
    }
}
// Problems: Poor naming, repetitive if statements, magic numbers, no constants
      

// Better: Complete the cycle with clarity and maintainability
public class DiscountCalculator
{
    private static readonly Dictionary<CustomerType, decimal> DiscountRates = new()
    {
        { CustomerType.Standard, 0.05m },
        { CustomerType.Premium, 0.10m },
        { CustomerType.VIP, 0.15m }
    };

    public decimal Calculate(decimal amount, CustomerType type)
    {
        if (!DiscountRates.TryGetValue(type, out var rate))
            throw new ArgumentException($"Unknown customer type: {type}");
        
        return amount * rate;
    }
}
// Benefits: Clear intent, easy to add new types, magic numbers have context,
// DRY principle applied, easy to test and modify
      

// Bad: Testing implementation
[Fact]
public void GetUser_CallsRepository_AndReturnsUser()
{
    var mockRepo = new Mock<IUserRepository>();
    mockRepo.Setup(x => x.GetById(1)).Returns(new User { Id = 1, Name = "John" });
    
    var service = new UserService(mockRepo.Object);
    var user = service.GetUser(1);
    
    // This test is overly detailed about HOW it works
    mockRepo.Verify(x => x.GetById(It.IsAny<int>()), Times.Once);
    Assert.Equal("John", user.Name);
}

// If we refactor to use a cache or a different repository, this test breaks
// even if the behavior (returning the correct user) is unchanged.
      

// Better: Test behavior
[Fact]
public void GetUser_ReturnsCorrectUser()
{
    var service = new UserService(new InMemoryUserRepository());
    var user = service.GetUser(1);
    
    Assert.NotNull(user);
    Assert.Equal(1, user.Id);
    Assert.Equal("John", user.Name);
    
    // Now you can refactor the internals without breaking this test
}
      

// Bad: Slow test
[Fact]
public void ProcessOrder_WithRealDatabase()
{
    // This hits the real database - could take seconds!
    var dbContext = new OrderDbContext(ConnectionString);
    var repository = new OrderRepository(dbContext);
    var service = new OrderProcessor(repository);
    
    service.ProcessOrder(new Order());
    
    // Assertion...
}

// Better: Fast unit test with mocked repository
[Fact]
public void ProcessOrder_QuickFeedback()
{
    var mockRepository = new Mock<IOrderRepository>();
    var service = new OrderProcessor(mockRepository.Object);
    
    service.ProcessOrder(new Order());
    
    // Assertion...
    // This runs in milliseconds.
}
      

// Don't test everything. Test what matters:
// 1. Business logic and algorithms
// 2. Edge cases and error handling
// 3. Integration points with external systems
// 4. Not: simple getters, property setters, or framework code
      

// TDD the logic...
[Fact]
public void CartTotalCalculator_WithThreeItems_ReturnsCorrectSum()
{
    var calculator = new CartTotalCalculator();
    var total = calculator.Calculate(new[] { 10, 20, 30 });
    Assert.Equal(60, total);
}

// Don't test: "Button is in the top-right corner"
// That's for visual regression tests (Percy, Chromatic) or manual testing.
// They're better suited for catching visual regressions than unit tests.
      

// Characterization test: Document what the code does, even if it's not perfect
[Fact]
public void LegacyProcess_BehavesAsDocumented()
{
    var result = LegacyClass.OldMethod("input");
    Assert.Equal("expected_output", result);
}

// This test documents current behavior. Now you have a safety net to refactor.
      

// Use BenchmarkDotNet for performance validation
[MemoryDiagnoser]
public class SortingBenchmark
{
    private int[] _data;

    [GlobalSetup]
    public void Setup() => _data = new int[10000].Select(_ => Random.Shared.Next()).ToArray();

    [Benchmark]
    public void QuickSort() => Array.Sort(_data);
}
// Run: dotnet run -c Release --benchmarkdotnet