Last week, I’ve re-read “Test Driven Development: By Example” by Kent Beck. I was amazed by the simplicity of his process, consisting of small pragmatic steps. So, I decided to put the process to the test in an unfamiliar domain.

The kata

In this kata, I am going to develop a serverless service in AWS using a Lambda and the API Gateway. I chose this task because, on the one hand, it will contain a fair amount of infrastructure code, which is considered hard to test. On the other hand, because I wanted a task that was more abstract and closer to a business requirement in contrast to a technical requirement like ‘deploy an AWS HTTP API Gateway’.

This is a blog post about the trade-offs I’ve observed during agile software delivery with test driven development (TDD). Agile and TDD are amazing, and I use them daily. My hope is that by raising awareness about the trade-offs of our decisions, while applying Agile and TDD, will help us make better decisions.

Agile software development

Agile software development is a balance of two priorities.

• On the one hand, we need to develop an application that satisfies the current requirements completely, correctly and economically.

When developing a new feature, I found that the use of the Null Object pattern can help keep the code releasable and naturally leads to the creation of a feature toggle.

Introduction

Every time I need to add some new functionality in my application, I face the same challenges, I need to make sure that my every commit does not introduce any regressions and also that I commit often so that my teammates and I always work on the latest code.