Ship code faster with TDD and small Pull Requests

Fig 01: A huge Pull request can take a long time to review

When considering the development phase of software, we often overlook the time taken for reviewing code. Large and complex changes might lead to unforeseen delays in reviewing and merging code, and this in turn delays delivery.

Consider this:

1. The story at hand is fairly complex and has an assigned value of 8 story points where 1 is the lowest 13 is the highest.
2. The story cannot be broken down further

And this is the story:

“A developer should be able to modify the name, quantity, and price, of a line item in an order — through a REST endpoint.

Before modifying a line item, the API should inspect whether it is a valid line item and if it hasn’t been sent to the kitchen already.”

A developer takes up this story and delivers the story as a single pull request. Let’s assume the pull request is:

Fig 02: Large pull request containing full code change

This pull request contains changes that are more than 500 lines, which makes code reviewing much harder and more time-consuming. On top of this, if some reviewer finds an issue with the code, refactoring could be a huge process. One thing you can do to ease this, is to create multiple smaller pull requests with incremental changes. The problem with this though, is that if the story is huge, reviewers don’t have any guarantee that the pull requests provided have any value. And that is where TDD comes in.

TDD or Test-driven development is a software development process that aims to deliver code that relies on very short development cycles. If you want to know more about TDD, you could read the following article from Martin Fowler: https://martinfowler.com/bliki/TestDrivenDevelopment.html

What brings value to this, is that now, developers are able to make valid pull requests in between TDD cycles. Because of TDD, the changes contained in pull requests are guaranteed to have value. So now, changes can be merged into the main development branches.

Because the actual pull requests are often smaller, they can be reviewed and merged faster, hence improves the time for delivery.

Using this method, we can break the changes in code required to accomplish the above story into these units.

• Validate if the item is modifiable (hasn’t been sent to a kitchen already, and the item is available)
• Validate the “name” parameter of the request, and modify the line item
• Validate the “price” parameter of the request and modify the line item
• Validate the “quantity” parameter of the request and modify the line item

Engaging in the development of these units individually, with writing unit tests first and then producing bare minimal code to pass those will enable the developer to produce multiple small pull requests incrementally.

These are the outcomes for the units identified:

Fig 03: Validating if an item is modifiable

Fig 04: Unit to which allows changing item name

Fig 05: Unit which allows changing item quantity

The above pull requests contain changes in a couple of hundred lines. Due to their size, they are easy to comprehend and review.

To conclude, the main takeaways from this are,

• TDD produces code with value at the end of a cycle
• Larger pull requests may require a huge amount of time and this can often lead to delays
• Smaller incremental pull requests can help improve delivery time.

Combining creating smaller pull requests with TDD practices let developers add valuable code into the main development branches fast