Test-Driven Development & the 4-step-rule

Photo by J. Kelly Brito on Unsplash

What’s TDD and why is so important to teach software developers to follow this approach?

The fact is that prioritizing tests over code implementation leads to testable code that directly translates into a more maintainable software product. This control over the code ends improving team efficiency to detect any bug or irregularity in features behavior and fix it. Also implies that you ensure to meet client expectations and criteria.

Photo by Ferenc Almasi on Unsplash

How is that?

Your team translate the acceptance criteria into tests and watch after the code is able to accomplish the requirements from the client. If then you develop trying to meet the expectations of those tests, you end it up making sure that your product will get client needs.

So, how to apply it? When I’m under TDD I use the 4-step-rule:
1. Write the tests (obvious)
2. Write the code
3. Complete the tests
4. Refactor that mess

1. Write the test
I strongly recommend following “Testing on the Toilet” practices and his principles.

Concretely “Keep Test Focused” and “DAMP”.

You must write the test thinking that code is already done. Here is where you will really declare your variables. You will be watching your task description while you’re developing your code so you make sure it will be doing whatever it should do.

2. Write the code
Make the thing. You just need to fill the gaps, following the clues that the tests left.

3. Complete the tests
There will be things that you cannot test until you had developed the feature. Make sure all your tests still passing, even those that are not yours.

4. Refactoring
Now you got to solve that mess. Leave it clean and smooth again, or even better if you can. I recommend using Sonarqube to make sure your code is healthy. Remember, getting a top-quality and easy-to-maintain product is our principal goal.

In addition, Test-Driven Development makes a perfect marriage with Agile.

Think about it. Combining TDD with the daily meeting where your team can adjust details to the client’s needs and translating that into more specific tests.

Seems like the magic formula.

Despite all, TDD is not paradise. The same old villain lurks over TDD. Bad practices. You will reduce it drastically by checking Sonarqube but you still will need to make sure to watch out to manage it.

TDD is more of a mindset. TDD puts maintenance and quality of code over speed and anxiety in the developing process. TDD implies efficiency and healthy code. Also drives the team to a constant relationship with code and his health while refactoring. That teaches them good practices.

--

--

--

Software Engineer and passionate software developer

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

The Eloqua Extension Cookbook

Upgrade to Redshift DC2 Nodes to Double Query Performance at the Same Cost

Getting Rust-y — III

Introducing Polycorn.Finance !

Learn SCSS (Sass) Part 2

MedEx : Laboratory Test Booking

Jenkins CD on Kubernetes

Design Patterns

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Curro Soria Ferrer

Curro Soria Ferrer

Software Engineer and passionate software developer

More from Medium

Chrome extension development with Clean Architecture (a PoC)

Let’s Learn SOLID — Introduction

How unit test can enhance our code quality?