Back to Home

Test Driven Development - Intro

Published on

Test Driven Development Best Practices

Test driven development: The process is in the name, we write applications with test in mind.

I will aim to introduce test driven development in such a way that it is programming language agnostic. It is not a tool of any sorts, it is a technique.

The process

Think first:

Break down the problem at hand. This involves having to get out your whiteboard pens, and start drawing out your thought process for your application/feature. This whiteboarding session can be directly driven from application requirements. Taking things slower and properly planning out how you will go about programming, will help you in the long run.

Occasionally at this phase you are able to share with your stakeholders potential problems, highlight key areas, and share progression, all without putting your hands on a keyboard.

Write tests: Red

Write a test for a single requirement based on your whiteboarding thinking. If the test is far too complex, then that is a suggestion that maby the requirement is too large, and should be split up into smaller requirements. The overall requirement is the same, so your stakeholder will be happy, but if you break things down further, you will be able to plan out the requirements in an agile way; defining sprints for each user story/ requirement.

Write code: Green

Write the most simple solution to pass your test, if you write any more code past this, you are no longer test driven developing, if you are coding ahead past the pass, this means that your test is not properly defined, that it does not fully define the requirement at hand.

Writing the most simple solution, ensures that you do not get carried away. It ensures you are thinking only about the most important business requirements, for a managerial perspective, writing anything further is a distraction and should be minimised.

Cleanup code: Refactor

Refactoring is the only step where you are allowed to code whilst your test is passed. You are not adding any additional feature, if you want to add more features, you must redefine you test, then add that new feature.

Refactoring means that you are cleaning up the code base. Your simple solution to pass the test, may not be elegant enough, sure it may be good enough for you, but a developer must always leave good in a neat condition for collaboration. Even if it is only you on the project, without neat code, best believe.. you will not understand what you wrote those years prior.

Furthermore, in addition to making your code more readable, and maintainable, you must ensure that the code meets business/ regulatory standards. Ensure that your code is consistent to the project, and looks like a quality solution.

Repeat.. Until complete.