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:

1. Create steering files – Put together steering files to capture our testing standards
2. Let Kiro help refine them – Use Kiro’s chat to polish both files based on what’s worked for us in the past
3. Set them to auto-include – Add YAML headers with inclusion: auto so these rules kick in automatically whenever we’re creating or tweaking tests
4. 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
5. Built the unit-test-writer subagent – Create another agent that takes those gaps and generates comprehensive test files following our conventions
6. 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
7. 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. 

---
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:

---
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:

---
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 hooks are 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:

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.

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.

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

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:

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.

MS Tech summit is a conference dedicated to Microsoft technology with 100+ speakers and 8 concurrent tracks. The conference is both Virtual and in person.

In my talk I will show how to develop .NET applications using AWS services and C# and the tools and services .NET developer can use to run their code in the cloud.

As a bonus there’s a 30% discount if you register before May 10th.

If you haven’t heard about NDC Oslo – you should! It’s one of the leading software developer conference it’s a 5 day event with more than 180 sessions delivered by 165+ speakers many of which are leaders in their field.

I will be speaking about how to plan and write automated tests for ASP.NET microservices.

I’ll talk about the different types of tests, how to write unit, integration and end to end tests for you microservices and how to test your applications running in your data center or in the cloud.

When not presenting I plan to be at the AWS booth, answering questions on .NET and cloud computing.

So there you have it, if you attend on of these conferences, stop by and say hello.

Since then, I have worked in many other companies and learnt how to write better code but I have always had a place in my heart for using matrix transformations to render 3D worlds using colors, reflections, lighting and shadows. That’s why when I’ve saw a book titled: “The Ray Tracer Challenge” I knew I had to get it. The book teaches how to build a 3D renderer form scratch – using test first (TDD/BDD) approach.

Since it was a long time since I’ve learned a new programming language I’ve decided to use Rust to and so I’ll re-learn something old (3D graphics, lighting) and something new (Rust).

I have been using JetBrains Rust plugin (running inside CLion) and it has been easy to use, all of the refactoring options, hints and run configurations – just work and make writing Rust code a breeze.

I have reached chapter 4 so far and have been fun learning a new language and getting thigs to appear on the screens (only dots so far – but I’m getting there), you can check my efforts on GitHub, I have been trying to find time each week to progress a but, unfortunately/luckily I have just committed myself to yet another project (I promise more details in a couple of months) so my Rust endeavor will suffer. I am, looking for feedback – it’s hard to tell how things supposed to be done when starting a new language, how to name your files – do you write all of the struct code in the same place, and so on.

My experience with Rust

so far it seems that Rust is a highly opinionated language, I get warnings when I write the wrong casing for method names or name my files not according to the standards – and I like it, although I’m not sure what some developers would do if they cannot argue about the right place to put their curly brackets.

Other than that, I found Rust to be simple to use once you get how methods are declared, operators “overloaded” and forget all you ever knew about inheritance and method overloading and learn how to use (and not abuse) macros, it’s a bit painful at first but then things do become a little simpler.

Rust is a safe programming language – just as advertised, it’s impossible to shoot yourself in the foot, in fact whenever you try Rust will explain why you’re an idiot and suggest what you should have done, that is one thing I wish more compilers will do, whenever I got a compilation error the compiler told me what I did wrong, and how I might correct it. It made learning Rust so simple, although I still get the nagging feeling that I’ve used ‘&’ incorrectly, but I get that in C++ from time to time, so I guess all is well. Writing code where everything is immutable as the default, cannot be null is so liberating and helps avoid writing those checks we <insert language here) developers are so familiar with, and the rust compiler really makes an effort to help you, finding unused code or suggest a better way to initialize your variables.

But there are a few downsides here, Rust is a relatively new language and some of the core libraries are still begin developed, some of the tools and frameworks are not there yet, for example the “unit testing framework” is a set of minimal macros and that’s it, and sometimes the type system feels too rigid – for example you decide on the size of an array when you write the code (otherwise use Vector) and in fact an array of 10 items is a type of its own which is a different type from an array of 5 items, it opens a few possibilities (as I discovered when creating matrices) but close a few others.

All in all, I enjoy writing code in Rust, its quick and intuitive but different from my Day Job’s Java/C++/C# work.

What I think about the book

Before I start talking about how much I like this book, a word of warning (or disclaimer if you will), if you intend to learn BDD or TDD from this book – walk away, this book does not intend to teach you how to write good tests or even how to write tests at all, there are better books for that depending on your language of choice.

In fact I find some of the tests to be “less than ideal” with strange inputs, multiple asserts, not covering all of the possible scenarios, writing more than one test before rushing to the implementation and other small sins in the Test first world – but that is not the point of this book.

This book does something different, Instead of explaining about Points, vectors, matrices and lighting it helps you create working software, one test at a time, by writing the test then the implementation I find I understand better the concepts and code, and by the way, the book does not have code snippets – just pseudo code and Gherkin like features/tests for you to write and implement.

I really do like the book, it helps you write tedious code in an interesting way (I mean how interesting can multiplying a vector can be), and in the end of almost every chapter you get to use the code you’ve implemented to create a working piece of software and see the code you wrote run.

And I do like this book, instead of just reading how things are done – you get to participate, in a well written, well thought of lesson, and have something to show for at the end.

So, if you’re interested in 3D rendering or just want to learn something new – I highly recommend this book. Read it, write the tests and then the code, other than programming, no prior knowledge needed.

Happy Coding…

When you develop micro services it it twice as important, usually you deploy your services individually and you need to know which version of which dependency is used by your service. Another requirement many developer face is how to automatically (or manually) update your dependencies when they change.

At one of my client’s projects we had a single repository with all of the services, which were built and deployed individually, as part of our continuous integration and deployment we’ve wanted to build only the services that were either changed or one of it’s dependencies has changed. I’ve also wanted to make sure that it’s easy to add new services to our system.

Then I found about the Versions Maven Plugin which can be used to automatically update versions to your maven projects and it automatically make sure to update all the other projects that dependent on it.

In my example project (source in GitHub) I have three services. Each service has a server and contract projects and service2 depends on service1 contracts and services3 depends on both service1 and service2.

Each service has a folder with it’s own pom file with sub folder for each sub-service.

I’ve needed a central place to manage all of services versions so I’ve added the following to the main (aggregator) pom.xml:

<properties>
    . . .

    <!-- Versions -->
    <service1.version>1.1-SNAPSHOT</service1.version>
    <service2.version>2.1-SNAPSHOT</service2.version>
    <service3.version>3.1-SNAPSHOT</service3.version>

I’ve wanted to automatically update the versions in the service pom.xml file when a service versions changes so I’ve added the following in the aggregator pom.xml:

<properties>
    . . .
    
    <!-- auto version related -->
    <service.version>0</service.version>
    <version.update.enable>generate-sources</version.update.enable>
    <version.phase>none</version.phase>
    <service.name>-invalid-</service.name>    
    . . .

</properties>
<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>2.7</version>
            <executions>
                <execution>
                    <phase>${version.phase}</phase>
                    <goals>
                        <goal>set</goal>
                    </goals>
                    <id>update-version</id>
                    <configuration>
                        <generateBackupPoms>false</generateBackupPoms>
                        <artifactId>${service.name}*</artifactId>
                        <newVersion>${service.version}</newVersion>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

I’ve added three new properties that would be set from each individual service:

• version.phase – this is when the versioning plugin would run, I needed it to run before compilation so I’ve defined a new property called version.update.enable with the correct version phase. The default is set to a non existent phase so that the versioning would only run for the services I need them to run.
• service.name – the service artifact name, for service1 it would be service1, I’ve used ${service.name}* because I’ve wanted all of the sub-projects (.server and .contracts) to have the same version.
• service.version – here I’ll set the service version, I’ve done a trick here, as you’ll see in a minute.

Now in each service (service1\pom.xml) we have to add the following lines:

<properties>
    <service.name>service1</service.name>
    <version.phase>${version.update.enable}</version.phase>
    <service.version>${service1.version}</service.version>
</properties>

Now each service defines it’s name (same as directory), set the version.phase using version.update.enable (which is set to generate-sources) and set the value of the version to the property defined in the root’s pom.xml.

Now if you update the version run mvn compile the version will be updated automatically:

Using this method we were able add versioning to all of our existing microservices and create new services easily – and it worked like a charm.

So there you have it, automatic version update for all dependent versions with a single update, which cause all of the effected services to be built once committed.

Happy coding…

This time it’s unit testing in C using JetBrains excellent CLion IDE. I did not know what to expect from unit testing in C course but once I’ve started recording I found myself adding more and more content until by the end of it I’ve found that on top of covering unit testing and CLion integration, I’ve also found time (late at night) to add a quick introduction in mocking methods in C.

If you’ve been wondering how to test your C code or interested on learning more about what CLion can do for you – check out my Unit Testing C Code in CLion course.

I have been tiring especially with schools closing then opening (and closing again) and on top of that finding the time and place to record has been a bigger challenge than it used to be, since most of my family has been home most of the time. But it’s done now and now I get to rest – at least for a couple of days.

The good news – now I hope to find more time to blog, I have quite a few posts I’ve been meaning to write but just could not find the time.

Until then – happy coding…

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"

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:

1. Create a new builder class
2. Copy the fields you need from the original class
3. Set default values for all fields
4. Create a build function using a constructor – or if you must setter methods
5. Generate all of the setter methods as build methods with a click of your keyboard (alt+insert)
6. 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…

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:

1. The method running the test – this is the play button that would be used to execute the “experiment”
2. 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”.
3. 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…

I was not easy, it took my all of my AWS experience as well as studying every day (and night) – but I got there.

What’s now? not sure, I’m going to relax a bit, keep writing software and blogging (obviously).

And maybe once the current crisis will be over I’ll start talking at conferences again.

Until then – happy coding…

Ingredients

• You’ll need to have a valid AWS account, if you never, ever used AWS you can sign up for the free tier.
• Visual Studio Community Edition – preferably 2019 (the current latest and greatest)
• Install AWS Toolkit for Visual Studio

Once you have everything installed you get to the fun part where we get to do stuff.

Creating the initial code

This is simpler than you think:

Step 1 – Open Visual Studio
Step 2 – create a new project
Step 3 – Choose a serverless application of a language of your choosing (C# of course)

Step 4 – fill project name, folder etc.
Step 5 – choose as blueprint, those are great starting points that will help you get up and running.

At this point you will have code that looks familiar to anyone who ever wrote an ASP.NET Core API project in the past but it would run as a Lambda function behind API Gateway:

There’s quite a lot there both good examples on how to use Rest API by adding Controller and logic that would enable running the Lambda’s code locally (under IIS), but for the purpose of this post I’d like to focus on serverless.template file.

Infrastructure as code using serverless.template

There are a few ways to define your resources as script/code, one of those is AWS CloudFormation which let you define your functions, buckets and other resources using “easy” to read and quite-confusing-to-write syntax. There are better ways to author Cloud Formation templates such as AWS-CDK or in this case AWS SAM (Serverless Application Model).

SAM is built on top of Cloud Formation with Lambda based applications in mind and the initial template looks something like this:

...
"Resources": {
    "AspNetCoreFunction": {
      "Type": "AWS::Serverless::Function",
      "Properties": {
        "Handler": "AWSServerless2::AWSServerless2.LambdaEntryPoint::FunctionHandlerAsync",
        "Runtime": "dotnetcore3.1",
        "CodeUri": "",
        "MemorySize": 256,
        "Timeout": 30,
        "Role": null,
        "Policies": [
          "AWSLambdaFullAccess"
        ],
        "Environment": {
          "Variables": {
            "AppS3Bucket": {...}
          }
        },
        "Events": {
          "ProxyResource": {
            "Type": "Api",
            "Properties": {
              "Path": "/{proxy+}",
              "Method": "ANY"
            }
          },
          "RootResource": {
            "Type": "Api",
            "Properties": {
              "Path": "/",
              "Method": "ANY"
            }
          }
        }
      }
    },
    "Bucket": {...}
    }
  },

After running the wizard we’ll end up with a Lambda function, and a Bucket (which we won’t talk about today).

The Lambda function defines the API gateway’s paths, see the path defined as /{proxy+}? this means that calls arriving to the API gateway will be forwarded to the Lambda functions to be handled by our Controller(s).

Right now, you can update the code and deploy the newly created Lambda from Visual Studio. I could do that and call it a day, but in my case I’ve needed to add API key to my API gateway…

Tweaking the solution – adding API Keys

In order to use API key, we need to define a usage plan and update the Lambda/API Gateway definitions.

First, we’ll start by defining the API Gateway’s properties, it was hidden in the background until now but now we’ll need to explicitly define it under Resources:

"ApiGatewayApi": {
    "Type": "AWS::Serverless::Api",
    "Properties": {
        "StageName": "Prod",
        "Auth": {
            "ApiKeyRequired": "true"
        }
    }
}

• We needed to add this definition to add “ApiKeyRequired”: “true”

Now we’ll need to update the Lambda Events to use the new API Gateway definitions:

"AspNetCoreFunction": {
    "Type": "AWS::Serverless::Function",
    "Properties": {
        ...
      "Events": {
            "ProxyResource": {
                "Type": "Api",
                "Properties": {
                    "Path": "/{proxy+}",
                    "Method": "ANY",
                    "RestApiId": {
                        "Ref": "ApiGatewayApi"
                    }
                }
            },
            "RootResource": {
                "Type": "Api",
                "Properties": {
                    "Path": "/",
                    "Method": "ANY",
                    "RestApiId": {
                        "Ref": "ApiGatewayApi"
                    }
                }
            }
        }
    }
},

• We’ve used RestApiId to create a connection between the new API Gateway definition and the Lambda Endpoint.

And Finally define the new API key, usage plan and connect the two:

"ApiUsagePlan": {
    "Type": "AWS::ApiGateway::UsagePlan",
    "Properties": {
        "ApiStages": [
            {
                "ApiId": {
                    "Ref": "ApiGatewayApi"
                },
                "Stage": "Prod"
            }
        ],
        "Throttle": {
            "BurstLimit": 200,
            "RateLimit": 100
        }
    }
},
"ApiUsagePlanKey": {
    "Type": "AWS::ApiGateway::UsagePlanKey",
    "Properties": {
        "KeyId": {
            "Ref": "ApiKey"
        },
        "KeyType": "API_KEY",
        "UsagePlanId": {
            "Ref": "ApiUsagePlan"
        }
    }
},
"ApiKey": {
    "Type": "AWS::ApiGateway::ApiKey",
    "Properties": {
        "Name": "my-api-key-name",
        "Enabled": "true",
        "StageKeys": [
            {
                "RestApiId": {
                    "Ref": "ApiGatewayApi"
                },
                "StageName": "Prod"
            }
        ]
    }
}

And we’re done, if you deploy the Lambda using the new SAM definitions you’ll have an Lambda behind an API Gateway, protected by a key which you need to pass in each message in the header (x-api-key). You can open your AWS console, navigate to your region of choice, and find the API key in the API Gateway page and then send that API key to the client and you’re done.

Obviously, you’ll need to add authentication/authorization but that’s a story for a different time…

And until then – happy coding…