DEV Community: Dror Helper

Using Kiro Subagents to Improve Test Coverage

Dror Helper — Mon, 30 Mar 2026 12:07:47 +0000

Every developer knows the sinking feeling. A “simple” change breaks production. You realize there were no tests catching the edge case. Poor test coverage means longer debugging sessions, more production incidents, and that nagging anxiety every time you deploy. But here’s the catch-22: going back to add tests to existing code feels like an overwhelming task. Where do you even start?

That’s where Coding AI changes the game. You don’t need to spend days writing tests for legacy code. Coding AI tools like Kiro can analyze your existing codebase. They understand the logic and generate comprehensive unit tests in minutes. You get the safety net of high test coverage without the manual grind. This frees you to focus on building new features. You don’t have to play archaeological detective with old code.

In this blog post you’ll learn how to leverage Kiro, Steering files and Subagents to dramatically improve your test coverage. This enhancement applies to existing projects. It turns that technical debt into a competitive advantage.

The Demo Application: Bob’s Used Bookstore

For this blog post, I’m using Bob’s Used Bookstore—an open-source .NET sample application from AWS that demonstrates real-world eCommerce functionality. Originally built as a monolithic ASP.NET Core MVC application, Bob’s Used Bookstore is a fictional second-hand book marketplace with both customer and admin portals.

What makes Bob’s Used Bookstore ideal for demonstrating unit test coverage improvements is its realistic complexity without overwhelming scope. It includes actual business logic, like order processing, inventory management, and shopping carts. It also features service integrations and a well-structured codebase. The repository is available at GitHub.

The Complete Workflow

There are plenty of ways to improve test coverage with AI. Your mileage may vary depending on your codebase, team conventions, and testing philosophy, here’s the workflow I used to go from minimal coverage to 96 comprehensive unit tests:

Create steering files – Put together steering files to capture our testing standards
Let Kiro help refine them – Use Kiro’s chat to polish both files based on what’s worked for us in the past
Set them to auto-include – Add YAML headers with inclusion: auto so these rules kick in automatically whenever we’re creating or tweaking tests
Built the test-gap-analyzer subagent – Create a custom agent that systematically scans the codebase to find all the missing unit tests and organizes them into units of work
Built the unit-test-writer subagent – Create another agent that takes those gaps and generates comprehensive test files following our conventions
Create an orchestration hook – Set up a manually-triggered hook that runs the gap analyzer first, then spins up multiple unit-test-writer agents in parallel to knock out all the missing tests
Ran the workflow – Hit play on the hook and watch Kiro analyze the codebase, partition the work, and generate 96 new unit tests in just a few minutes

Teaching Kiro Unit Testing Best Practices

One of Kiro’s most powerful features is steering. This is the ability to guide its code generation with custom instructions. These instructions encode your team’s best practices. You can save time by using steering to “teach” Kiro your unit testing standards upfront. This way, there’s no need to manually review and correct every AI-generated test. For example, you can specify naming conventions, like MethodName_Scenario_ExpectedBehavior. You can enforce patterns like Arrange-Act-Assert, require specific assertion libraries, or mandate edge case coverage.

And so the first thing to do is to “First you’ll need”teach” Kiro how an ideal unit test should look like – using steering files.

I have created two files unit-tests.naming-conventions.md and unit-tests.xunit-assertion-rules.md and used Kiro’s agentic chat to edit both files based on my preferences and experience.

Steering files support several inclusion modes. These modes define when the steering file is used as part of the chat context. Both files are only valid when writing unit tests. You should add the next header to your steering files. This ensures your unit testing standards are consistently enforced whenever you create or change tests without manual activation.

Copy

---
inclusion: auto
name: unit tests assertion rules
description: assertion rules for unit tests. Use when creating or modifying unit tests.
---

Once the unit testing rules are defined in steering files, you can start working on unit tests. These include best practices and preferences.

Creating the Test Gap Analyzer Subagent

Instead of writing a simple prompt I’ve decided to use an agent. Kiro’s subagents transform code analysis by running specialized tasks in parallel, each with its own dedicated context window. Instead of overwhelming a single conversation with your entire codebase, you can analyze test coverage gaps. You can also evaluate dependencies. Additionally, you can assess code quality. Each task is handled by subagents focused on specific missions. This parallel architecture means faster insights and more precise recommendations. Each analysis maintains clean, isolated context. This prevents the pollution that degrades results when mixing multiple concerns in one thread.

You can define your own custom agent by creating a markdown (.md) file in ~/.kiro/agents (global) or <workspace>/.kiro/agents (workspace scope). Enter the prompt for the custom agent in the body of the markdown file. Define extra attributes as YAML front matter. After I had the first agent in place I’ve asked Kiro to review and improve it and got the next agent definition:

<button type="button" data-copy-text="---
name: test-gap-analyzer
description: Analyzes the codebase to identify missing unit tests by examining business logic classes and methods, mapping external dependencies, and producing a structured report of test gaps organized by units of work.

tools: ["read"]

You are a test gap analyzer. Your job is to analyze a codebase and identify missing unit tests.
Use the workspace steering files (in .kiro/steering/) to understand the project structure, tech stack, testing frameworks, and conventions before starting analysis. Do NOT assume any specific project layout — discover it from steering files and by exploring the codebase.

Analysis Process

Follow these steps strictly:

Step 1: Understand the Project

Read all steering files in .kiro/steering/ to learn the project structure, dependency flow, tech stack, test frameworks, and conventions.
Identify the source directories, test directories, and how the project is organized.

Step 2: Discover All Business Logic

Scan the solution to identify:

All classes and methods that contain business logic (primary candidates for unit tests)
All logic that interacts with external dependencies such as databases, HTTP clients, file systems, or message queues (candidates for integration tests)

Step 3: Discover Existing Tests

Scan all test projects to catalog what is already tested. Map each existing test to the class/method it covers.

Step 4: Identify Test Gaps

Compare Step 2 and Step 3 to find untested business logic. Focus on:

Service classes with business rules
Entity methods and computed properties
Validation logic
Controller/handler action methods with business logic
Helper/utility methods with logic

Step 5: Organize into Units of Work

Group the identified gaps into discrete units of work. Each unit of work should represent a logical grouping of related functionality. For each unit of work, determine:

Target class and methods — what specifically needs tests
Test type — unit test or integration test
Dependencies to mock — which interfaces/services need to be faked
Test project — which test project the tests belong in
Priority — High (core business logic, calculations, state changes), Medium (validation, filtering, mapping), Low (simple getters, pass-through methods)

Output Format

Produce a structured report with:

Summary — total classes analyzed, total methods analyzed, existing test count, gap count
Existing Test Coverage — list of what's already tested
Units of Work — each unit formatted as:

### Unit of Work: [Name]
- **Target** : [Class.Method or Class (multiple methods)]
- **Test Type** : Unit Test | Integration Test
- **Test Project** : [project name]
- **Priority** : High | Medium | Low
- **Dependencies to Mock** : [list of interfaces]
- **What to Test** : [bullet list of specific behaviors/scenarios to verify]
- **Notes** : [any relevant context]

Important Rules

Tests must target business logic BEHAVIOR, not implementation details. Focus on what the code does, not how it does it internally.
Do NOT suggest tests for trivial property getters/setters with no logic.
Do NOT suggest tests for auto-generated code or migrations.
Do NOT suggest integration tests for simple CRUD methods that just delegate to a data framework.
DO suggest tests for any method that contains conditional logic, calculations, state transitions, or validation.
DO suggest tests for data access methods that contain custom query logic beyond simple CRUD.
When identifying dependencies to mock, list the interface name, not the concrete implementation." hidden>Copy

---
name: test-gap-analyzer
description: Analyzes the codebase to identify missing unit tests by examining business logic classes and methods, mapping external dependencies, and producing a structured report of test gaps organized by units of work.

tools: ["read"]

---

You are a test gap analyzer. Your job is to analyze a codebase and identify missing unit tests.
Use the workspace steering files (in `.kiro/steering/`) to understand the project structure, tech stack, testing frameworks, and conventions before starting analysis. Do NOT assume any specific project layout — discover it from steering files and by exploring the codebase.

## Analysis Process

Follow these steps strictly:

### Step 1: Understand the Project

- Read all steering files in `.kiro/steering/` to learn the project structure, dependency flow, tech stack, test frameworks, and conventions.

- Identify the source directories, test directories, and how the project is organized.

### Step 2: Discover All Business Logic

Scan the solution to identify:

- All classes and methods that contain business logic (primary candidates for unit tests)

- All logic that interacts with external dependencies such as databases, HTTP clients, file systems, or message queues (candidates for integration tests)

### Step 3: Discover Existing Tests

Scan all test projects to catalog what is already tested. Map each existing test to the class/method it covers.

### Step 4: Identify Test Gaps

Compare Step 2 and Step 3 to find untested business logic. Focus on:

- Service classes with business rules

- Entity methods and computed properties

- Validation logic

- Controller/handler action methods with business logic

- Helper/utility methods with logic

### Step 5: Organize into Units of Work

Group the identified gaps into discrete units of work. Each unit of work should represent a logical grouping of related functionality. For each unit of work, determine:

1. **Target class and methods** — what specifically needs tests

2. **Test type** — unit test or integration test

3. **Dependencies to mock** — which interfaces/services need to be faked

4. **Test project** — which test project the tests belong in

5. **Priority** — High (core business logic, calculations, state changes), Medium (validation, filtering, mapping), Low (simple getters, pass-through methods)

## Output Format

Produce a structured report with:

1. **Summary** — total classes analyzed, total methods analyzed, existing test count, gap count

2. **Existing Test Coverage** — list of what's already tested

3. **Units of Work** — each unit formatted as:

Unit of Work: [Name]

Target : [Class.Method or Class (multiple methods)]
Test Type : Unit Test | Integration Test
Test Project : [project name]
Priority : High | Medium | Low
Dependencies to Mock : [list of interfaces]
What to Test : [bullet list of specific behaviors/scenarios to verify]
Notes : [any relevant context]


## Important Rules

- Tests must target business logic BEHAVIOR, not implementation details. Focus on what the code does, not how it does it internally.

- Do NOT suggest tests for trivial property getters/setters with no logic.

- Do NOT suggest tests for auto-generated code or migrations.

- Do NOT suggest integration tests for simple CRUD methods that just delegate to a data framework.

- DO suggest tests for any method that contains conditional logic, calculations, state transitions, or validation.

- DO suggest tests for data access methods that contain custom query logic beyond simple CRUD.

- When identifying dependencies to mock, list the interface name, not the concrete implementation.

This subagent definition creates a test gap analyzer that systematically identifies missing unit tests in a codebase. Here’s the breakdown by high-level structure:

Lines 1-4 – Header: agent definition, name, description, read-only tool access

Lines 6-8 – Purpose: audits test coverage by identifying missing unit tests

Lines 10-41 – Process: five steps to understand project structure, discover business logic, catalog existing tests, find gaps, and organize into prioritized units of work

Lines 43-60 – Output: structured report with summary, coverage list, and detailed units of work (target, type, project, priority, dependencies, test scenarios)

Lines 62-70 – Rules: focus on behavior over implementation, skip trivial code, emphasize logic with conditionals/calculations/validation, mock interfaces not implementations

Running the agent is done by starting a new “Vibe” session and using /test-gap-analyzer from Kiro’s chat:

Creating Subagent to Add Missing Unit Tests

Now that you have the test gap analysis it’s time to add the missing unit tests. I have created another subagent to help add the missing tests and saved it’s definition in unit-test-writer.md (because naming is hard).

The subagent creates a unit test writer that systematically generates comprehensive test coverage based on gap analysis, while respecting existing project conventions and minimizing invasive changes to production code:

<button type="button" data-copy-text="---
name: unit-test-writer
description: Creates unit test files based on test gap analysis output. Reads steering files for project conventions, naming standards, and assertion rules before writing tests.

tools: ["read", "write", "shell"]

You are a unit test writer. Your job is to create unit test files based on units of work provided to you, typically from a test gap analysis.

Process

Step 1: Read Steering Files

Read all steering files in .kiro/steering/ to learn the project structure, tech stack, test frameworks, naming conventions, and assertion rules.
Follow all conventions defined in steering files strictly. Do NOT redefine or override them.

Step 2: Examine Existing Tests

Look at existing test files to understand the established patterns: imports, class structure, test method style, how mocks are set up, how test data is created.
Reuse existing builders, helpers, and shared infrastructure where available.

Step 3: Read the Source Code

For each unit of work, read the target class and its dependencies to fully understand the behavior being tested.
Identify all code paths, edge cases, and boundary conditions.

Step 4: Write the Tests

Create test files in the appropriate test project following the discovered conventions.
Each test file should cover one unit of work (one class or closely related group of methods).
Write tests that verify behavior, not implementation details.

Step 5: Validate Per Project

After finishing all test files for a specific test project, run dotnet test on that project to verify tests compile and pass.
Fix any failures before moving on to the next project.

Step 6: Final Validation

After all test files are written across all projects, run dotnet test on the entire solution to verify everything works together.
Fix any failures found.

Test Writing Rules

Write UNIT TESTS only. Do not write integration tests.
All naming conventions and assertion rules are defined in the steering files. Follow them — do not duplicate or redefine them here.
Mock all external dependencies using the project's mocking framework.
Each test method should verify one logical behavior/scenario.
Use Arrange-Act-Assert pattern.
Include edge cases: null inputs, empty collections, boundary values, error conditions.
Do NOT test trivial getters/setters, constructors with no logic, or auto-generated code.
Do NOT duplicate existing tests — check what already exists before writing.
Reuse existing test builders and helpers rather than creating new ones when possible.
Create new builders only when no suitable one exists for the class under test.
Place test files in the correct test project following the project's organizational pattern.

Source Code Modification Policy

Do NOT modify existing source code files (code under test) except in the following specific cases:
1. Extracting interfaces from existing classes to enable mocking of existing dependencies.
2. Updating constructors to enable dependency injection only when needed for injecting mocks for testing.
3. Updating project files (.csproj) to add InternalsVisibleTo attributes to allow mocking of internal classes.
Any other changes to production source code are strictly forbidden. Tests must be written against the existing code as-is." hidden>Copy

---
name: unit-test-writer
description: Creates unit test files based on test gap analysis output. Reads steering files for project conventions, naming standards, and assertion rules before writing tests.

tools: ["read", "write", "shell"]

---

You are a unit test writer. Your job is to create unit test files based on units of work provided to you, typically from a test gap analysis.

## Process

### Step 1: Read Steering Files

- Read all steering files in `.kiro/steering/` to learn the project structure, tech stack, test frameworks, naming conventions, and assertion rules.

- Follow all conventions defined in steering files strictly. Do NOT redefine or override them.

### Step 2: Examine Existing Tests

- Look at existing test files to understand the established patterns: imports, class structure, test method style, how mocks are set up, how test data is created.

- Reuse existing builders, helpers, and shared infrastructure where available.

### Step 3: Read the Source Code

- For each unit of work, read the target class and its dependencies to fully understand the behavior being tested.

- Identify all code paths, edge cases, and boundary conditions.

### Step 4: Write the Tests

- Create test files in the appropriate test project following the discovered conventions.

- Each test file should cover one unit of work (one class or closely related group of methods).

- Write tests that verify behavior, not implementation details.

### Step 5: Validate Per Project

- After finishing all test files for a specific test project, run `dotnet test` on that project to verify tests compile and pass.

- Fix any failures before moving on to the next project.

### Step 6: Final Validation

- After all test files are written across all projects, run `dotnet test` on the entire solution to verify everything works together.

- Fix any failures found.

## Test Writing Rules

- Write UNIT TESTS only. Do not write integration tests.

- All naming conventions and assertion rules are defined in the steering files. Follow them — do not duplicate or redefine them here.

- Mock all external dependencies using the project's mocking framework.

- Each test method should verify one logical behavior/scenario.

- Use Arrange-Act-Assert pattern.

- Include edge cases: null inputs, empty collections, boundary values, error conditions.

- Do NOT test trivial getters/setters, constructors with no logic, or auto-generated code.

- Do NOT duplicate existing tests — check what already exists before writing.

- Reuse existing test builders and helpers rather than creating new ones when possible.

- Create new builders only when no suitable one exists for the class under test.

- Place test files in the correct test project following the project's organizational pattern.

## Source Code Modification Policy

- Do NOT modify existing source code files (code under test) except in the following specific cases:
  1. Extracting interfaces from existing classes to enable mocking of existing dependencies.
  2. Updating constructors to enable dependency injection only when needed for injecting mocks for testing.
  3. Updating project files (`.csproj`) to add `InternalsVisibleTo` attributes to allow mocking of internal classes.

- Any other changes to production source code are strictly forbidden. Tests must be written against the existing code as-is.

Lines 1-4 – Header section – Agent definition with name, description, and tools (read, write, shell access)

Lines 6-7 – Core purpose – The agent acts as a unit test creator that generates test files from test gap analysis output

Lines 9-42 – Process workflow – Six-step methodology:

Step 1 : Read steering files to understand project conventions
Step 2 : Examine existing tests to learn established patterns
Step 3 : Read source code to understand behavior being tested
Step 4 : Write tests following discovered conventions
Step 5 : Validate per project using dotnet test
Step 6 : Final validation across entire solution

Lines 44-56 – Test writing rules – Enforce unit test best practices. Follow the AAA pattern. Mock dependencies. Cover edge cases. Avoid testing trivial code. Reuse existing test infrastructure. Prevent test duplication.

Lines 58-65 – Source code modification policy – Strictly limit changes to production code. Only allow interface extraction for mocking, constructor updates for dependency injection, and .csproj modifications for InternalsVisibleTo attributes. All other source modifications are forbidden.

With the two agents created – it’s time to add the final piece in the puzzle – orchestration.

Orchestrating Subagents using Kiro’s Agent Hooks

Agent hooksare powerful automation tools. They automate your development workflow by executing predefined agent actions. These actions turn on automatically when specific events occur in your IDE. With hooks, you remove the need to manually ask for routine tasks and guarantee consistency across your codebase.

But, in this case you do not need to use Kiro’s Hooks automatic triggering capabilities. Instead, we’ll use a manually triggered hook. We’ll use the hook to define and store the workflow to run the first subagent. Then, it will run the second subagent in parallel!

Creating a new Hook from the ‘+’ in Kiro’s menu:

Then choose Manually create a hook

Give a title and description. Make sure that the event type is Manual Trigger and in the action paste the next code:

<button type="button" data-copy-text="Run the test-gap-analyzer sub-agent to analyze the codebase and identify all missing unit tests.

Once the analysis is complete, run 'dotnet build' to verify solution build succesfully. Fix any errors before continuing to the next stage.

Then group the high-priority units of work by their target test project. Within each test project, further partition the units of work into non-overlapping batches so that no two batches create or modify the same test file. A good partitioning strategy is:

Batch by class-under-test category (e.g., entity tests vs. service tests) so each batch writes to different test files.
Each batch should list the exact unit-of-work names it must handle.

Then invoke multiple unit-test-writer sub-agents IN PARALLEL — one per batch. Each sub-agent prompt must:

Specify the exact units of work (by name) it is responsible for.
Specify which test files it should create (so there is zero overlap with other batches).
Include the full gap analysis context for those units.

IMPORTANT: No two parallel sub-agents may create or modify the same file. Partition so each agent owns distinct test files. After all parallel agents complete, run 'dotnet test' once on the full solution to validate everything compiles and passes." hidden>Copy

Run the test-gap-analyzer sub-agent to analyze the codebase and identify all missing unit tests.

Once the analysis is complete, run 'dotnet build' to verify solution build succesfully. Fix any errors before continuing to the next stage.

Then group the high-priority units of work by their target test project. Within each test project, further partition the units of work into non-overlapping batches so that no two batches create or modify the same test file. A good partitioning strategy is:

- Batch by class-under-test category (e.g., entity tests vs. service tests) so each batch writes to different test files.

- Each batch should list the exact unit-of-work names it must handle.

Then invoke multiple unit-test-writer sub-agents IN PARALLEL — one per batch. Each sub-agent prompt must:

1. Specify the exact units of work (by name) it is responsible for.

2. Specify which test files it should create (so there is zero overlap with other batches).

3. Include the full gap analysis context for those units.

IMPORTANT: No two parallel sub-agents may create or modify the same file. Partition so each agent owns distinct test files. After all parallel agents complete, run 'dotnet test' once on the full solution to validate everything compiles and passes.

After you save the hook you will see the new hook with a “play” button added under the Agent Hooks section, along with the steering files we’ve created:

With all the pieces in place, you can run the hook. Kiro runs a subagent to conduct a codebase-wide analysis. Then, it spins up multiple subagents to add the missing unit tests.

Kiro spins up a subagent to analyze and find the missing unit tests – then analyze the results and break the work down between multiple subagents that write new unit test tests across my codebase:

And finally, after a few minutes, Kiro has created 96 new unit tests. These tests will help catch bugs early. They allow confident refactoring and reduce deployment anxiety.

If you want to follow the how Kiro tracked than written missing unit tests – I have published the full run to YouTube (no audio)

Conclusion

Poor test coverage leads to production bugs, longer debugging cycles, and deployment anxiety. This solution shows the transformative power of Kiro. It combines steering files and specialized subagents. Kiro can turn technical debt into a competitive advantage. It automates comprehensive test generation in minutes rather than weeks.

The test-gap-analyzer subagent systematically audits your codebase. It identifies untested business logic. Meanwhile, the unit-test-writer subagent generates tests that follow your team’s established conventions. Together, they remove the manual burden of writing tests for legacy code. They uphold quality standards through steering files. These files encode your naming conventions, assertion rules, and architectural patterns.

Start enhancing your test coverage today. Teach Kiro your team’s standards. Let AI manage the repetitive work of test generation.

Kiro for Test-Driven Development (TDD)

Dror Helper — Mon, 16 Mar 2026 14:12:31 +0000

You’ve spent years mastering TDD’s red-green-refactor rhythm. Now AI coding assistants write code instantly. Should you abandon the discipline that made you a better developer, or do TDD and AI work together?

In this post I will use Kiro – an AI-powered IDE that enables developers build software from prototype to production through spec-driven development, intelligent agent assistance, and automated workflows.

Before we see how AI handles TDD, let’s revisit the cycle that makes it work: Red (write a failing test), Green (make it pass with minimal code), Refactor (clean up while keeping tests green). This rhythm isn’t just methodology—it’s the discipline that prevents us from writing code we don’t need.

For my experiment I’ve decided to use Roy Osherove’s “String Calculator TDD Kata“, however using such a well known TDD Kata results in the LLM solving it using one of the many implementations that already exist out there, so instead before starting I have asked my trusty AI to suggest a similar problem that was not tried before and so I present to you the _ Number Parser Kata _:

Objective: Create a function that parses written numbers in English and returns their numeric sum.

Parse written numbers (“one”, “two”, “three”) and return their sum
Progressively add: handling “and” connectors, compound numbers (“twenty-three”), negatives (“minus five”)
Examples
- parse("one") → 1
- parse("five") → 5
- parse("one two") → 3
- parse("one and two") → 3
- parse("thirteen and fifteen") → 28
- parse("minus five") → -5

You get the point, as a starting point I wanted to see if providing a clear task enables Kiro to write the solution test first.

“Teaching” Kiro about TDD using Steering files

For this TDD experiment, I created a steering file that explicitly taught Kiro the red-green-refactor cycle, ensuring it would write minimal failing tests first rather than jumping ahead to complete solutions.

Steering files are instruction documents you place in your project that teach Kiro your team’s coding practices and workflows—steering files encode your development methodology directly into the AI’s behavior.

Since I’m going to work on a “green field” application I’ve also added steering files outlining the tech used (python), project structure and testing best practices.

Kiro AI IDE workspace showcasing the organization of project structure, TDD workflow, tech, and test standards for streamlined development.

Here’s the key steering file that teaches Kiro TDD principles, notice lines 20-35, this was a crucial part that prevents Kiro from jmping ahead with implementation, writing one test then complete implementation without working step by step

---
inclusion: always
---

# TDD Workflow

## Philosophy
This project follows strict Test-Driven Development (TDD). All code must be written in response to a failing test. No production code exists without a corresponding test that drove its creation.

## The Red-Green-Refactor Cycle
- **Red** : Write a failing test that describes the desired behavior in plain English
- **Green** : Write the minimum production code to make the test pass — nothing more
- **Refactor** : Clean up the code while keeping all tests green

## Rules
- Never write production code before a failing test exists
- Tests must fail for the right reason before implementing
- Implement only what is needed to pass the current failing test
- After each green phase, consider if refactoring is needed
- All behavior must be described in plain English before generating a test

## What "Minimum" Means
**CRITICAL** : "Minimum" means the simplest possible code that makes ONLY the current test pass.

Examples of what NOT to do:
- ❌ Test checks "one" returns 1 → Don't implement a dictionary with "one" through "ten"
- ❌ Test checks addition of two numbers → Don't implement multiplication, division, etc.
- ❌ Test checks parsing a single word → Don't implement comma-separated parsing

Examples of correct minimal implementations:
- ✅ Test checks "one" returns 1 → Use `if numbers == "one": return 1`
- ✅ Test checks "two" returns 2 → Add `elif numbers == "two": return 2`
- ✅ After 3+ similar cases → Refactor to use a dictionary (driven by duplication, not anticipation)

**The Golden Rule** : If you can delete code and the test still passes, you wrote too much code.

**Resist the urge to be "clever" or "complete"**. Let the tests drive every single line of production code. Premature generalization violates TDD principles.

## Cycle Prompt Pattern
When asked to implement a feature, always:
1. First generate a failing test for ONE specific behavior
2. Confirm the test fails
3. Then generate the minimal implementation (see "What Minimum Means" above)
4. Confirm all tests pass
5. Suggest refactoring opportunities (only if duplication exists)
6. Review request and existing tests to find if additional tests are needed
   - If at least one more test is needed, start another cycle by writing a failing test
   - If not, declare that requirement was met

Break each feature into individual tasks for each step in the TDD lifecycle

## Self-Check Before Implementing
Before writing production code, ask yourself:
1. What is the EXACT assertion in the failing test?
2. What is the SIMPLEST code that makes that assertion pass?
3. Am I implementing anything the test doesn't verify?
4. If I remove this line, does the test still pass? (If yes, delete it)

Running the Red-Green-Refactor cycle

Now that I had my initial setup – I started with the first requirement:

Create a function that parses written numbers in English and returns their numeric sum. the method signature will be: int Add(string numbers).

If a single number is written then the output should be that number numeric value

And it worked! – Kiro Jumped in and created a first failing test followed by a trivial implementation

Test function for the Number Parser’s Add method, validating that the input ‘one’ returns the correct output of 1.

Kiro setup setup for a Number Parser in Python, from left to right: files, tests, implementation and agentic chat

And then continued to implement all numbers between 1-10 as well and tests for sum of two numbers – which was the test I expected – trivial and simple:

Python test function for adding multiple written number words, asserting that ‘one two’ equals 3.

All the time continuing the cycle of Red-Green-Refactor.

As Kiro ran, I noticed that while the code was refactored and improved, the tests remained the same. After Kiro finished, I asked for a test refactor and updated Kiro’s Steering file to ensure both tests and code would be refactored going forward.

Once all cycles were complete, I verified no additional tests were needed by requesting a quick test review. Kiro did jump ahead at one point—creating a parameterized test for all numbers between 4 and 10—but as someone who’s trained countless developers in TDD, this is a common “human behavior” if I ever saw one.

If you want to see the whole run (6min 50sec) you can check it on YouTube:

Conclusion

This experiment answered my initial question: Yes, TDD remains valuable in the age of AI coding assistants —not despite AI’s capabilities, but because of them.

Kiro followed the red-green-refactor cycle when guided by steering files that encoded TDD principles. It wrote failing tests first, implemented minimal solutions, and refactored code while keeping tests green. The Number Parser Kata demonstrated that AI practices disciplined development when properly instructed.

Kiro occasionally “jumped ahead” with parameterized tests—a behavior I’ve seen countless times when training human developers in TDD. This reinforced an important insight: we don’t abandon the practices that made us better developers in the world of agentic coding. Instead, we encode them into how we guide our AI tools.

Some argue AI’s ability to generate complex code with tests makes TDD obsolete. This experiment suggests otherwise: TDD provides the verification layer that ensures AI-generated code actually implements the specified behavior correctly. As AI coding assistants increase in capability, the discipline of TDD becomes more important, not less—it’s the guardrail that keeps us from accepting code that compiles but doesn’t solve the right problem.

Try this yourself: use the steering file from earlier in this post and give TDD with AI a spin.

Easily create builders for your tests using Intellij IDEA

Dror Helper — Mon, 26 Oct 2020 11:42:59 +0000

The builder pattern is one of the more useful patterns out there when creation unit tests.

Instead of having a huge initialization such as:


@Test
void validateUser_userNameIsEmpty_returnFalse(){
    var user = new User();
    user.setId("id-1");
    user.setName(null);
    user.setPhoneNumber("555-1234");
    // additional user initialization

   boolean result = userService.validate(user);

   assertFalse(result);
}

You can instead create a simple user builder object for your tests that would initialize all of the object’s properties with default values (not empty) – since you do not really care what the values are as long as they are valid and write the following test:


@Test
void validateUser_userNameIsEmpty_returnFalse(){
    var user = new UserBuilder()
                      .withName(null)
                      .build();

   boolean result = userService.validate(user);

   assertFalse(result);
}

It helps you reduce the test code avoid duplication and if the user’s class changes in some way you do not need to fix 100+ tests. But the real benefit is that using builders in your tests is that they help to focus the test reader on what’s important in this test. This is very important because the test reader might be you trying to understand why a test you wrote three months ago started failing at 8pm on the day before a major release.

If you want to learn more about object initialization you can check my post on the subject: "[On object creation and unit tests](https://helpercode.com/2013/12/22/on-object-creation-and-unit-tests/)"

The problem with builders

But it’s not all rainbows and sunshine when creation builders for your tests, it is also a painful experience, you need to create a new class, then add all of the values you need to set in that object, implement setter methods and build method and it’s not a fun experience which has caused me more often than not to avoid creationg builders until my test code has become too painful to maintain.

But that was in the past, since I found a cool new feature in Intellij, I found out that when I create setters for a class using code generation I can choose those setters to use the builder template.

Now creating builders for my tests is easy:

Create a new builder class
Copy the fields you need from the original class
Set default values for all fields
Create a build function using a constructor – or if you must setter methods
Generate all of the setter methods as build methods with a click of your keyboard (alt+insert)
Write tests using your new and shiny class.

Quick and simple, and relatively painless.

If you’re a .NET developer (I know I am) you might be wondering if the same feature exist in R# and/or Visual Studio (I know I did). Unfortunately it does not I guess it’s because it was never requested and properties in .NET are implemented differently. I guess you’ll have to ask JetBrains to add this feature or create your own code template.

And until Then… Stay healthy and happy coding…

Better tests names using JUnit’s display names generators

Dror Helper — Thu, 27 Aug 2020 08:57:59 +0000

Writing unit tests can be challenging, but there is one thing that can get you on the right track – the test name.

If you manage to give your test a good name – you will write a good test.

Unfortunately in some (read: many) unit testing frameworks the test name must be a valid method name – because those “unit tests” are actually functions inside a class and so they looks something like this:


public class CalculatorTests {

    @Test
    void add_passTwoPositiveNumbers_returnSum() {
        Calculator calculator = new Calculator();

        int result = calculator.add(2, 3);

        assertEquals(5, result);
    }
}

Test Names

In my tests I’ve been using the naming scheme created by Roy Osherove. It forces you to think about the test before you write it and keep you from writing horrible unit tests.

The test names are built from three parts:

The method running the test – this is the play button that would be used to execute the “experiment”
The scenario we test – what is the system state before running the method, what input is used during the test – in other words “what makes this test different from any other test ever written”.
The expected result – what we expect to happen when we run the method (1) with the specific state (2) .

The good thing about using structured test names is that when a test fails we understand immediatly what went wrong. Test names tells use what we’re testing and what we expect to happen and together with the error message (from an assertion) we should quickly understand what went wrong, fix it and have the code back to running smoothly in no time.

However – there is a problem

JUnit and it’s successor xUnit testing frameworks use methods and classes to host the “tests” and so the test “name” must be a valid function name, and so I find myself using underscores and camel-case/pascal-case to help the reader of the method locate and understand the words I’m using.

It seems that in 2020 we’re still haven’t grasp the idea that test names do not have to be method names at least not in mainstream unit testing frameworks. I know some unit testing frameworks enable writing text as the test names but usually when I get to a company the are using one of the popular unit testing framework which does not).

The JUnit5 solution – test name generators

JUnit5 did try and solve this issue, by adding thee ability to mark your test with a test name generator:


@DisplayNameGeneration(TestNameGenerator.class)
public class CalculatorTests {

    @Test
    void add_passTwoPositiveNumbers_returnSum() {
        Calculator calculator = new Calculator();

        int result = calculator.add(2, 3);

        assertEquals(5, result);
    }

The display name generators can be one of the pre-packaged name generators such as DisplayNameGenerator.ReplaceUnderscores that will automatically replace the underscores in you test names with spaces or you can write your own by extending one of the DisplayNameGenerator classes or by implementing DisplayNameGenerator interface.

Then you can either use the @DisplayNameGenerator annotation on your test classes or methods or you can create junit-platform.properties file and add the line:

junit.jupiter.displayname.generator.default = <your DN generator>

My solution

I’ve wanted to split the test names into the three parts and then add brackets around the method tested and have a test name that looks: (_ method _): _ scenario _ -> _ expected result _ and so I wrote the following code:


public class TestNameGenerator extends DisplayNameGenerator.Standard {
    private String splitToParts(String input) {
        try {
            List<String> stringParts = getTestNameParts(input);

            if (stringParts.size() == 1) {
                return input;
            }

            if (stringParts.size() == 2) {
                return String.format("(%s): Always %s", stringParts.get(0), stringParts.get(1));
            }

            if (stringParts.size() == 3) {
                return String.format("(%s): %s -> %s", stringParts.get(0), stringParts.get(1), stringParts.get(2));
            }

        } catch (Exception exc) {
            System.console().writer().println("Failed parsing test name");
        }

        return input;
    }

    private List<String> getTestNameParts(String input) {
        List<String> stringParts = new ArrayList<>();
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < input.length(); ++i) {
            char ch = input.charAt(i);
            if (ch == '(') {
                break;
            }
            if (ch == '_') {
                stringParts.add(sb.toString());
                sb.setLength(0);
            } else if (Character.isUpperCase(ch) && stringParts.size() > 0) {
                if (sb.length() > 0) {
                    sb.append(" ");
                }
                sb.append(Character.toLowerCase(ch));
            } else {
                sb.append(ch);
            }
        }

        stringParts.add(sb.toString());
        return stringParts;
    }

    @Override
    public String generateDisplayNameForMethod(Class<?> testClass, Method testMethod) {
        return splitToParts(
                super.generateDisplayNameForMethod(testClass, testMethod)
        );
    }
}

It’s quite a lot but it’s basically replacing underscores (‘_’) with spaces (‘ ‘) and splitting to words based on upper case letters and also I’ve wanted to handle cases in which there are two parts to the test name.

Now when I run the tests I see the following results:

Which is exactly what I want, having readable test names helps me write better test names, it’s hard to hide when it’s written in pain English and writing good test names helps me write better tests – but we’ve already covered that

Happy coding…