In many software projects, testing usually becomes an afterthought as much of the effort is dedicated towards building the functionality of the application.
Writing new features is rightfully a more interesting and exciting task than writing tests. However, having a suite of tests to verify that the functionality you are writing is working is very important.
Writing tests is all well and good, but writing them based on code you have already written often leads to having tests that work around the already-implemented code. In order to have tests that are reliable and help increase the confidence in the robustness of your code we should be writing them in a way that is independent of the application’s code. This means that these tests should pass as long as the expected behaviour is seen from the application, regardless of how that behaviour is implemented.
Moreover, it is a good idea to write the tests first and let the test cases direct how the expected functionality is implemented. This is known as Test Driven Development (TDD).
In the software development industry most teams now use TDD when developing new functionality or fixing bugs/defects in the code. Personally, I have taken to this methodology of developing code because it allows me to plan what I will be implementing as I am writing a test case which will pass if the necessary conditions are met.
The basic flow of TDD can be seen as:
- Write a test case that will pass only if a required condition is met.
- Run the test, it will fail as the required functionality isn’t implemented yet.
- Write the minimum amount of code in your application which will make this test pass.
- Run the test, it should pass as you have implemented something that outputs what the test case expects.
- Refactor the code. (eliminate code duplication, improve/optimise code etc.)
Using TDD you will end up defining how your application is developed using tests that expect some new functionality to be developed. This way, you can define the structure of your methods and functions in a logical and well thought-out way which can save you countless hours of refactoring if you had written them first and had to adapt them to make them testable.
You will also have a really good percentage of code coverage (the proportion of code that is executed as part of your test cases) as you are always writing functionality that is required by a test case to pass. This means that a large amount of your code will be covered by tests from the outset and you won’t have to dedicate time specifically for writing tests after implementing functionality, which often leads to poorly written tests.
In this post I talked about how Test Driven Development is used to develop software by first writing test cases which then influence the development of the functionality in the application’s code. This approach results in code that has an associate suite of reliable tests which help make the application more robust.
TDD can also positively influence the quality of the code that is written and certainly helps in developing an application with a well laid out code structure and design.