DEV Community

itysu tur
itysu tur

Posted on

AI-Assisted TDD vs. Pure TDD: I Picked the Iterative Dance

#dotnet #csharp #tutorial #ai

AI-Assisted TDD vs. Pure TDD: I Picked the Iterative Dance

How do you maintain a true test-first discipline when an AI assistant is constantly itching to write the implementation before you've even finished the test? That question gnawed at me for months.

I've been a TDD advocate for years, but the rise of AI coding assistants like GitHub Copilot and Claude Sonnet 4.6 threw a wrench in my process. My usual rhythm of red-green-refactor felt constantly disrupted. I needed a way to leverage the AI without losing the benefits of TDD, especially on a new .NET 9 project I was kicking off. I wanted a true ai tdd dotnet workflow, not just AI generating code around my tests.

My Initial Missteps and the 'Premature Implementation' Trap

Honestly, my first attempts at integrating AI into my TDD cycle were a mess. I'd typically prompt something like, "Write a C# 13 method to reverse a string, then write a unit test for it." And almost every time, the AI—whether it was Copilot's inline suggestion or a full response from Claude Opus 4.7 in Cursor 0.42—would spit out the implementation first, then a test that simply confirmed its own code. It wasn't TDD; it was "implementation-driven development with a side of AI-generated validation."

This felt like cheating, or at best, missing the point. The value of TDD, for me, lies in defining behavior before coding, letting the tests guide the design. When the AI gives you the answer upfront, that crucial design step is skipped. I might be wrong about this, but for me, the magic of TDD is in the constraint, the thinking it forces. The AI's eagerness to complete the thought was a constant hurdle.

Here’s a simplified version of what I kept getting, and what I was actively trying to avoid:

// My initial prompt (mental or explicit): "I need a method to safely parse an int from a string."
// AI's eager response, often before I've even thought of edge cases:
public static class StringParser
{
    public static int ParseIntOrDefault(string input, int defaultValue = 0)
    {
        if (int.TryParse(input, out int result))
        {
            return result;
        }
        return defaultValue;
    }
}

// And then, a test for it, which is useful but didn't guide the *design*:
[TestFixture]
public class StringParserTests
{
    [Test]
    public void ParseIntOrDefault_ValidInput_ReturnsParsedValue()
    {
        Assert.That(StringParser.ParseIntOrDefault("123"), Is.EqualTo(123));
    }

    [Test]
    public void ParseIntOrDefault_InvalidInput_ReturnsDefault()
    {
        Assert.That(StringParser.ParseIntOrDefault("abc"), Is.EqualTo(0));
    }
}
Enter fullscreen mode Exit fullscreen mode

The implementation was often fine, but it bypassed my brain's TDD muscle memory. I was constantly running into this "premature implementation" trap.

The Rhythm I Found: Test-First Prompts

It took me an embarrassing amount of time to figure out: I needed to treat the AI like a highly capable, but literal, junior developer who needed very specific instructions. The key was to constrain the AI to only generate the test, and then, once I'd seen it fail, to ask for the implementation. This became my core tdd ai pair strategy.

What I ended up with was a two-stage prompting approach, primarily using Cursor 0.42's chat for the initial test generation and then Visual Studio 2026 with Copilot for quick completions on the implementation.

First, I'd prompt for the test, often specifying C# 13 and .NET 9 context:

"I'm working in C# 13 with .NET 9. I need a unit test for a new static method `GuidUtils.IsValidGuid(string s)`.
It should handle null, empty, invalid format strings, and a valid GUID. Focus ONLY on the test, no implementation."
Enter fullscreen mode Exit fullscreen mode

Claude Sonnet 4.6 would then give me something wonderfully focused like this, which I'd drop into my test project:

using NUnit.Framework;
using System;

[TestFixture]
public class GuidUtilsTests
{
    [Test]
    public void IsValidGuid_NullString_ReturnsFalse()
    {
        Assert.That(GuidUtils.IsValidGuid(null), Is.False);
    }

    [Test]
    public void IsValidGuid_EmptyString_ReturnsFalse()
    {
        Assert.That(GuidUtils.IsValidGuid(""), Is.False);
    }

    [Test]
    public void IsValidGuid_InvalidFormat_ReturnsFalse()
    {
        Assert.That(GuidUtils.IsValidGuid("not-a-guid"), Is.False);
    }

    [Test]
    public void IsValidGuid_ValidGuid_ReturnsTrue()
    {
        Assert.That(GuidUtils.IsValidGuid(Guid.NewGuid().ToString()), Is.True);
    }
}
Enter fullscreen mode Exit fullscreen mode

I'd run the tests, watch them all fail (red!), and then I'd prompt the AI for the implementation, often feeding it the failing test code as context, or just referencing the method signature:

"Implement the `GuidUtils.IsValidGuid` method in C# 13 to make the above tests pass. Keep it efficient."
Enter fullscreen mode Exit fullscreen mode

And then, the AI would provide the minimal code to get to green:

using System;

public static class GuidUtils
{
    public static bool IsValidGuid(string s)
    {
        return Guid.TryParse(s, out _);
    }
}
Enter fullscreen mode Exit fullscreen mode

This felt like genuine test driven ai. I was still driving the behavior definition, and the AI was an incredible accelerator for getting to the green state.

Where I'm Still Tweaking: Refactoring and Edge Cases

So, where am I now? I'm firmly in the camp of ai tdd pair as a viable, productive workflow. My test suites are growing faster, and I'm catching more edge cases upfront because the AI is so good at suggesting test scenarios. It’s particularly strong for utility methods and well-defined algorithms.

However, the journey isn't over. Refactoring, for instance, is still a tricky area. While I can prompt the AI to "refactor this C# method to improve readability," it often suggests a full rewrite based on patterns rather than an incremental, behavior-preserving refactor that I'd typically do with TDD. I find myself doing more of the refactoring manually, using the AI more for brainstorming ideas for refactorings rather than the actual code changes. Also, for complex domain logic with subtle business rules, I still often write the first few tests myself to truly embed my understanding. Your mileage may vary, but for me, the test generation part remains the biggest win.

The biggest remaining challenge for me is leveraging AI for complex domain modeling during the design phase, before any code or tests are written.

If you've tried to pair TDD with AI in a .NET context, especially for refactoring existing codebases, I'd love to hear what broke or what surprising workflows you discovered.

Top comments (0)