TDD in .NET: Refactoring Safely

Picture this: You join a new team, and your first task is to fix a bug in a legacy billing module. The method is 300 lines long, filled with cryptic variable names and nested ifs. You hesitate—what if you break something? This fear is universal. But with a solid suite of tests, refactoring transforms from a risky gamble into a safe, even enjoyable, process. Tests are your safety net, letting you clean up code with confidence.

In TDD, refactoring opportunities emerge naturally from your test suite. Focus your refactoring efforts where they'll have the biggest impact:

• High-churn areas with weak tests: Code that changes often but lacks comprehensive test coverage is a refactoring candidate. Write tests first (characterization tests if it's legacy code), then refactor safely.
• Failing or flaky tests: If tests are hard to write or maintain for a feature, the underlying code likely needs refactoring. Use the test feedback as a signal that design is off.
• Repetitive test patterns: Duplicated test logic or setup code suggests the production code should be simplified. Refactor to reduce test boilerplate.
• Complex test assertions: If verifying behavior requires many assertions or helper methods, the code under test is probably doing too much. Refactor to single responsibility.

Refactoring isn’t rewriting, slowing down, or sneaking in new features. It’s about improving the internal structure without changing what the code does. The challenge? Sometimes the code is so tangled, or so poorly tested, that even small changes feel risky. If you’ve ever tried to clean up a function and ended up breaking something, you know the pain.

Step-by-step walkthrough:

1. Before refactoring: Each service calculates discounts independently, leading to bugs when business rules change.

   
       public class OrderService
       {
           public decimal CalculateTotal(Order order)
           {
               decimal discount = 0;
               if (order.CustomerType == "Senior") discount = order.Total * 0.15m;
               else if (order.CustomerType == "Premium") discount = order.Total * 0.10m;
               return order.Total - discount;
           }
       }
   
       public class CartService
       {
           public decimal CalculateTotal(Cart cart)
           {
               decimal discount = 0;
               if (cart.CustomerType == "Senior") discount = cart.Total * 0.15m;
               else if (cart.CustomerType == "Premium") discount = cart.Total * 0.10m;
               return cart.Total - discount;
           }
       }
               

   
   
2. Write tests first: Cover all discount scenarios to lock in expected behavior.

   
       [Fact]
       public void CalculateDiscount_SeniorCustomer_ShouldReturn15Percent() => 
           Assert.Equal(150m, calculator.CalculateDiscount(100m, "Senior"));
   
       [Fact]
       public void CalculateDiscount_PremiumCustomer_ShouldReturn10Percent() => 
           Assert.Equal(90m, calculator.CalculateDiscount(100m, "Premium"));
   
       [Fact]
       public void CalculateDiscount_RegularCustomer_ShouldReturnNoDiscount() => 
           Assert.Equal(100m, calculator.CalculateDiscount(100m, "Regular"));
               

   
   
3. After refactoring: Extract discount logic into a single, reusable class.

   
       public class DiscountCalculator
       {
           public decimal CalculateDiscount(decimal total, string customerType) => customerType switch
           {
               "Senior" => total * 0.15m,
               "Premium" => total * 0.10m,
               _ => 0m
           };
       }
   
       public class OrderService
       {
           private readonly DiscountCalculator discountCalc = new();
           public decimal CalculateTotal(Order order) => 
               order.Total - discountCalc.CalculateDiscount(order.Total, order.CustomerType);
       }
   
       public class CartService
       {
           private readonly DiscountCalculator discountCalc = new();
           public decimal CalculateTotal(Cart cart) => 
               cart.Total - discountCalc.CalculateDiscount(cart.Total, cart.CustomerType);
       }
               

   
   
4. Benefit: Fix a bug once, fix it everywhere. Change senior-citizen discount from 15% to 20%? Update one line in `DiscountCalculator`. All three services benefit immediately. Tests ensure nothing breaks.

If it’s not covered by tests, don’t refactor it.

1. Identify what the code does (read, run, and document its outputs)
2. Write tests that lock its current behavior (characterization tests)
3. Refactor safely in tiny steps
4. Run tests after every micro-change

Tests are your seatbelts. If you don’t have them, write them first—even if they just confirm the current (possibly weird) behavior.

TDD (Test-Driven Development) makes refactoring a natural part of coding. Here’s how:

1. Red: Write a test for a new or existing behavior. Watch it fail (proves the test is valid).
2. Green: Make the test pass with the simplest code possible.
3. Refactor: Now, clean up the code. The tests guarantee you don’t break anything.

Example: Your shipping calculator has a bug: express shipments should cost $15 flat, but the system is incorrectly charging weight-based rates instead.

1. Red: Write a test that locks in the correct behavior:

   
       [Fact]
       public void CalculateExpressShippingFee_ShouldReturn15Flat()
       {
           var calculator = new ShippingCalculator();
           var result = calculator.CalculateExpressShippingFee(weight: 50); // weight shouldn't matter
           Assert.Equal(15m, result);
       }
               

   
   The test fails because the code applies weight-based logic to express shipments.
2. Green: Make the test pass with the simplest fix—hardcode $15 for express shipments or add a conditional check.
3. Refactor: Now that tests protect you, introduce a `ShippingStrategy` interface to handle different shipping types cleanly:

   
       public interface IShippingStrategy
       {
           decimal CalculateFee(decimal weight);
       }
   
       public class ExpressShippingStrategy : IShippingStrategy
       {
           public decimal CalculateFee(decimal weight) => 15m; // flat rate
       }
   
       public class StandardShippingStrategy : IShippingStrategy
       {
           public decimal CalculateFee(decimal weight) => weight * 0.5m;
       }
               

   
   All tests still pass. Both express and weight-tier shipping now work correctly, and adding new shipping types is easy.

Let’s walk through a real-world scenario. You’re tasked with refactoring an API method that calculates discounts for a shopping cart. It’s a monster:

• 150 lines long
• Duplicated logic for different product types
• Messy, nested conditionals
• No documentation

Before (giant nested ifs):

            public decimal CalculateDiscount(Cart cart)
            {
                if (cart.ProductType == "Electronics")
                {
                    if (cart.Price > 100)
                    {
                        return cart.Price * 0.9m;
                    }
                    else
                    {
                        return cart.Price * 0.95m;
                    }
                }
                else if (cart.ProductType == "Groceries")
                {
                    // ...more nested ifs...
                }
                // ...many more lines...
            }
        

After (small clean methods):

            public decimal CalculateDiscount(Cart cart)
            {
                switch (cart.ProductType)
                {
                    case "Electronics":
                        return ApplyElectronicsDiscount(cart);
                    case "Groceries":
                        return ApplyGroceriesDiscount(cart);
                    default:
                        return cart.Price;
                }
            }

            private decimal ApplyElectronicsDiscount(Cart cart)
            {
                return cart.Price > 100 ? cart.Price * 0.9m : cart.Price * 0.95m;
            }
            // ...other clean methods...
        

Here’s how you tackle it:

1. Step 1: Write tests confirming its current behavior (characterization tests). Example:

            // <summary>Verifies current discount logic for electronics</summary>
            [Fact]
            public void Discount_Electronics_ShouldBe10Percent()
            {
                var cart = new Cart { ProductType = "Electronics", Price = 100 };
                var result = DiscountCalculator.Calculate(cart);
                Assert.Equal(90, result);
            }
        

2. Step 2: Start micro-refactoring. Extract methods, rename variables, remove duplication, and introduce domain concepts. Example:

            // <summary>Extracted method for electronics discount</summary>
            private decimal ApplyElectronicsDiscount(Cart cart)
            {
                return cart.Price * 0.9m;
            }
        

3. Step 3: Keep running tests. If anything breaks, behavior changed—fix immediately. The tests will catch regressions before they reach production.

Boy Scout Rule: Leave the code cleaner than you found it.

• It’s readable
• Duplication is removed
• Structure makes sense
• No further clarity is gained

In TDD, refactoring patterns emerge from your Red-Green-Refactor cycle. Here are essential patterns and how they fit into TDD:

• Extract Method: Test reveals a method does too much? Extract a helper. Write a test for the extracted behavior first.
• Extract Class: When a class has too many responsibilities (and your tests for it are complex), split it. Tests guide which responsibilities belong together.
• Inline Variable: Overly complex intermediate variables make tests harder to read. Inline them once tests verify the logic.
• Rename for Intent: If a test name doesn't match what the code does, rename the code. Tests act as specifications.
• Introduce Parameter Object: When you have many parameters making tests verbose, group them. Tests tell you when parameters need organization.
• Replace Magic Numbers with Constants: Tests should use named constants, not magic numbers. This refactor improves both code and test readability.
• Replace Conditional with Polymorphism: Complex conditionals (if/else chains) are test nightmares. Strategy or State patterns simplify testing.

Example - Extract Method via TDD: Your test is failing because a method mixes currency conversion with discount calculation.

    [Fact]
    public void CalculatePrice_WithCurrencyAndDiscount_ShouldWorkCorrectly()
    {
        // This test is trying to verify too much at once
        var result = calculator.CalculatePrice(100m, "USD", "Senior");
        Assert.Equal(expectedValue, result);
    }
    
    // Refactor: Write separate tests
    [Fact]
    public void ConvertCurrency_USD_ShouldApplyCorrectRate() => ...
    
    [Fact]
    public void ApplyDiscount_SeniorCustomer_ShouldReturn15Percent() => ...
    
    // Now extract the methods to make tests pass
    private decimal ConvertCurrency(decimal amount, string currency) => ...
    private decimal ApplyDiscount(decimal amount, string customerType) => ...
        

Learn a few patterns and use them often. Let your tests guide which pattern fits best.

• Refactoring while adding new features
• Mixing feature changes and refactors in the same commit
• Editing tests to “make green” instead of fixing code
• Over-engineering
• Ignoring performance regressions

Example: A junior dev refactors a password validation function from 80 lines to 20 lines (cleaner logic, same behavior). But they also "optimized" the regex pattern. Two days later, users can't reset passwords because the regex now rejects valid special characters. The refactor and the "optimization" are tangled. If separated: the refactor alone would pass all tests, and the optimization would immediately fail password tests. Lesson learned the hard way.

• IDE automated refactorings (Rider/VS/IntelliJ)
• Mutation testing
• Linters & static analysis tools
• Coverage tools (for guidance, not targets)

            // Original code
            return cart.Price * 0.9m;
            // Mutated code (by tool)
            return cart.Price * 0.8m;
            // If your test still passes, it’s too weak!
            

Refactoring is a habit. TDD encourages frequent, safe refactors, cleaner designs, confidence in code, and higher quality with less fear. With tests as your safety net, refactoring becomes not just easy — but joyful. Next time you see a scary function, remember: write a test, refactor in small steps, and let your tests give you courage.