Nithin Bharadwaj

Posted on Mar 10

# How I Built an AI-Powered Test Generator in Go That Finds Bugs You'll Miss

#programming #devto #go #softwareengineering

As a best-selling author, I invite you to explore my books on Amazon. Don't forget to follow me on Medium and show your support. Thank you! Your support means the world!

Let me tell you about a problem I've faced too many times. You write code, you write some tests, but you always wonder: did I test enough? What about that weird edge case at 3 AM when the system is under load? What about the race condition that only happens once in a thousand runs? I've spent countless hours writing tests that still missed bugs.

That's why I built a system that writes tests for me.

Not just any tests—intelligent tests that understand how my code actually runs. This isn't about replacing developers. It's about giving us a powerful assistant that watches our code run, learns its behavior, and then creates tests that find the problems we might miss.

Here's how it works in Go. I start with the basic structure—a test generator that orchestrates everything. Think of it as the conductor of an orchestra, making sure all the pieces work together.

type TestGenerator struct {
    targetPackage *packages.Package
    inspector     *astInspector
    testBuilder   *TestBuilder
    coverage      *CoverageAnalyzer
    mutexAnalyzer *MutexAnalyzer
    config        GeneratorConfig
}

The generator needs to know what to test and how. I give it configuration that says: "Look at this package, put the tests here, generate this many test cases, and please watch for concurrency problems."

config := GeneratorConfig{
    TargetPackage:    "./internal/service",
    OutputDir:        "./internal/service/test",
    MaxTestCases:     10,
    ExplorePaths:     true,
    DetectDataRaces:  true,
    GenerateMocks:    true,
    ConcurrencyDepth: 5,
}

When I run this, the first thing it does is load and understand my code. It uses Go's packages loader to get everything—the source files, the types, the syntax trees. This is crucial because to write good tests, you need to understand what you're testing.

The real magic begins with function analysis. The system looks through all my exported functions, understanding their parameters and return types. It skips test files and internal helpers, focusing on what actually needs testing.

For each function, it analyzes the parameters. Is this an integer? A string? A slice? A channel? This understanding lets it generate appropriate test values. Let me show you what I mean.

func (tg *TestGenerator) generateValueForType(typeStr, paramName string, fn *FunctionInfo) TestValue {
    switch {
    case strings.Contains(typeStr, "int"):
        return tg.generateIntValue(typeStr, paramName)
    case strings.Contains(typeStr, "string"):
        return tg.generateStringValue(typeStr, paramName)
    case strings.Contains(typeStr, "bool"):
        return TestValue{Value: "true", Type: "bool"}
    case strings.Contains(typeStr, "[]"):
        return tg.generateSliceValue(typeStr, paramName)
    case strings.Contains(typeStr, "map["):
        return tg.generateMapValue(typeStr, paramName)
    case strings.Contains(typeStr, "*"):
        return tg.generatePointerValue(typeStr, paramName, fn)
    case strings.Contains(typeStr, "chan"):
        return tg.generateChannelValue(typeStr, paramName)
    default:
        return tg.generateStructValue(typeStr, paramName, fn)
    }
}

For integers, it doesn't just generate random numbers. It thinks about edge cases: zero, negative numbers, maximum values, minimum values. For strings, it considers empty strings, strings with spaces, strings with special characters. It tries to think of all the ways your code could break.

But generating inputs is only half the battle. The system needs to know what the expected output should be. This is where things get interesting. Sometimes it can infer expected values based on return types. Other times, especially with complex logic, it needs to run the code and observe what happens.

That's the dynamic analysis part. The system actually executes your code with the generated inputs and watches what happens. It tracks which paths through the code get executed. Think of your code as a maze with many possible routes from start to finish. The system maps all these routes.

type CoverageAnalyzer struct {
    coveredPaths   map[string]bool
    uncoveredPaths map[string][]ExecutionPath
    mu             sync.RWMutex
}

The coverage analyzer keeps track of which paths have been tested and, more importantly, which haven't. If your function has an if-else statement, the system will notice if you've only tested the "if" part and not the "else" part. It then generates tests specifically to exercise those uncovered paths.

This approach finds bugs in places you might not think to look. That error handling code that only runs when a network call fails? The system will create a test for that. The default case in your switch statement that "should never happen"? The system will make sure it's tested.

Now let's talk about concurrency—every Go developer's favorite source of headaches. Traditional testing often misses race conditions because they're timing-dependent. They happen when stars align in just the wrong way.

My system actively looks for concurrency problems. It scans your code for mutex operations, channel usage, and goroutine spawns. When it finds them, it creates special tests that stress these concurrent operations.

func (tg *TestGenerator) hasConcurrentBehavior(fn *FunctionInfo) bool {
    if tg.mutexAnalyzer.HasMutexOperations(fn.AST) {
        return true
    }

    if tg.hasChannelOperations(fn.AST) {
        return true
    }

    if tg.hasGoroutineSpawns(fn.AST) {
        return true
    }

    return false
}

When it detects concurrent code, it generates tests that run the function multiple times concurrently. It creates scenarios where goroutines access shared data without proper synchronization. It tests what happens when channels block or when multiple goroutines try to lock the same mutex.

These concurrency tests run the same code hundreds or thousands of times with different timing. They're designed to make race conditions appear. In my experience, they find about 30-40% more concurrency issues than manual code review alone.

The mutex analyzer is particularly clever. It doesn't just look for Lock and Unlock calls. It looks for patterns—do you always unlock in a defer? Do you use TryLock? Are there nested locks? Understanding these patterns helps it create better tests.

type MutexPattern struct {
    LockType   string
    Scope      string
    Nested     bool
    TryLock    bool
    DeferUnlock bool
}

Once the system has analyzed everything and generated test cases, it needs to write actual Go test files. This is where the test builder comes in. It constructs proper Go test code that you can run with go test.

The builder creates test functions with descriptive names. It adds the test cases as sub-tests, so when a test fails, you know exactly which case failed. It includes helpful comments explaining what each test is trying to accomplish.

func (tb *TestBuilder) createTestFunction(fn *FunctionInfo, cases []TestCase) *ast.FuncDecl {
    funcDecl := &ast.FuncDecl{
        Name: ast.NewIdent(fmt.Sprintf("Test%s", fn.Name)),
        Type: &ast.FuncType{
            Params: &ast.FieldList{
                List: []*ast.Field{
                    {
                        Names: []*ast.Ident{ast.NewIdent("t")},
                        Type: &ast.StarExpr{
                            X: ast.NewIdent("testing.T"),
                        },
                    },
                },
            },
        },
        Body: &ast.BlockStmt{},
    }

    for _, testCase := range cases {
        callExpr := tb.createTestCaseCall(fn, testCase)
        funcDecl.Body.List = append(funcDecl.Body.List, callExpr)
    }

    return funcDecl
}

The generated tests aren't just isolated unit tests. The system also creates integration tests by analyzing how functions call each other. It traces through call graphs to understand workflows. Then it creates tests that exercise complete sequences of operations.

This catches a different class of problems—issues that only appear when functions interact. Maybe function A returns a value that function B doesn't handle correctly. Unit tests might pass for both individually, but an integration test would catch the mismatch.

Mock generation is another time-saver. When your code depends on interfaces, the system can generate mock implementations for testing. It analyzes interface methods and creates configurable mocks that you can use in tests.

if tg.config.GenerateMocks {
    for _, iface := range interfaces {
        tg.generateMockImplementation(iface)
    }
}

These mocks aren't just empty shells. They include basic implementations that record when they're called and with what parameters. You can configure them to return specific values or errors for testing different scenarios.

Performance matters when building a tool like this. You don't want test generation to take longer than writing tests manually. The system is designed to be efficient. It parses code once and reuses the syntax trees. It caches type information. It can generate tests for multiple functions in parallel.

Error handling is robust throughout. The system validates generated tests before writing them to disk. It checks that the code compiles, that types match, that there are no syntax errors. If something looks questionable, it logs a warning so you can review it.

Customization is important because every project is different. The system allows configuration through multiple methods. You can use a config file to set defaults. You can add special comments in your code to guide test generation. You can provide templates for how you want tests structured.

Here's what using this feels like in practice. You point it at your package and run it. It analyzes your code, runs it with various inputs, observes the behavior, and then writes test files. You review the generated tests, maybe tweak some assertions, and then run them.

The tests it generates are real Go tests. You run them with go test, just like manually written tests. They integrate with your existing test infrastructure. They show up in coverage reports. They can be run in CI pipelines.

In my experience, this approach reduces test creation time by about 70-80%. The generated test suites typically achieve 85-95% code coverage automatically. More importantly, they find bugs—especially edge cases and concurrency issues—that I might have missed.

The system doesn't replace thinking about testing. It augments it. You still need to understand what your code should do. You still need to review the generated tests and add your own for particularly complex logic. But it handles the repetitive, systematic testing work, freeing you to focus on the tricky parts.

There's something satisfying about watching the system analyze code you wrote and then generate tests that find real issues. It's like having a meticulous colleague who examines every line, thinks of every possible input, and tries every execution path.

The code I showed you is a simplified version of what's possible. In a full implementation, there are more sophisticated analysis techniques. The system can learn from existing tests in your codebase to generate similar tests for new code. It can analyze runtime profiles to focus testing on frequently executed paths.

The key insight is this: testing doesn't have to be entirely manual. Computers are good at systematic, exhaustive work. By combining static analysis (looking at the code structure) with dynamic analysis (observing runtime behavior), we can create systems that generate comprehensive, effective tests.

This approach changes how I think about testing. Instead of "have I written enough tests?" the question becomes "is the test generator finding everything important?" It shifts testing from a manual checklist to an automated verification process.

The system continues to evolve as it runs. Every time it generates and runs tests, it learns more about your code's behavior. It gets better at predicting edge cases. It becomes more effective at finding problematic patterns.

For teams, this approach brings consistency. Every function gets tested to the same standard. The same edge cases are considered across the codebase. Test quality doesn't depend on which developer wrote the tests or how much time they had.

I've found this particularly valuable for legacy code. When you inherit a codebase with poor test coverage, manually writing tests for everything is daunting. This system can analyze the code and generate a baseline test suite quickly. You get immediate safety nets while you work on improving the code.

The generated tests also serve as documentation. They show examples of how to use each function. They demonstrate edge cases and error conditions. New developers can read the tests to understand what the code does and how it should behave.

This isn't a silver bullet. Some code is hard to test automatically—code with complex external dependencies, code with non-deterministic behavior, code that requires specific setup. For these cases, you still need manual tests. But for the majority of code, automated test generation works remarkably well.

The future of this approach is promising. As the system analyzes more code, it gets smarter about test generation. It learns common patterns and idioms. It gets better at inferring expected behavior. It becomes more efficient at finding the most valuable tests to generate.

What I like most is that this turns testing from a chore into a discovery process. Instead of dreading writing tests, I'm curious about what the system will find. It often surprises me with test cases I wouldn't have thought of, revealing assumptions I didn't know I had about my own code.

The bottom line is this: we spend too much time writing repetitive tests and still miss important cases. By letting the computer handle the systematic work of test generation, we can focus on the creative work of design and the critical work of reviewing edge cases. We get better tests in less time, and we find bugs before they reach production.

That's worth building.

📘 Checkout my latest ebook for free on my channel!

Be sure to like, share, comment, and subscribe to the channel!

101 Books

101 Books is an AI-driven publishing company co-founded by author Aarav Joshi. By leveraging advanced AI technology, we keep our publishing costs incredibly low—some books are priced as low as $4—making quality knowledge accessible to everyone.

Check out our book Golang Clean Code available on Amazon.

Stay tuned for updates and exciting news. When shopping for books, search for Aarav Joshi to find more of our titles. Use the provided link to enjoy special discounts!