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.

Not sure where to start? Focus your refactoring efforts where they’ll have the biggest impact:

• High-churn areas: Code that changes often is more likely to accumulate bugs and technical debt. Clean it up first.
• Pain points: Functions or modules that frustrate you or your team—slow to understand, hard to modify, or error-prone.
• Repetitive code: Copy-pasted logic or duplicated patterns are prime candidates for extraction and simplification.
• Frequent bugs: If a part of the codebase is always breaking, refactor it to make future fixes easier.

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.

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: In a logistics app, a developer added a test for a buggy shipment fee calculation. After making it pass, they refactored the fee logic into a clean, reusable method—knowing the test would catch any mistakes.

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

• Extract Method
• Extract Class
• Inline Variable
• Rename for Intent
• Introduce Parameter Object
• Replace Magic Numbers with Constants
• Move Method
• Encapsulate Collection
• Replace Conditional with Polymorphism

Learn a few — not all. Use them often. Try applying one pattern in your next refactor and see the difference.

• 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

• 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.