If you researching Agile or methods to improve your testing or code delivery, no doubt you’ve heard of Test-Driven development (TDD). But why are so many people talking about TDD these days? Let's explore this and answer your specific question regarding the benefits.
What are the benefits of Test-Driven development? Fewer defects, speed of delivery, more cost effective, easier to test and more efficient code.
The reality is there are many benefits for TDD. Whilst these are the main benefits, it Is important to see why these are benefits and understand how this can benefit your business or career as a tester.
TDD is developer centric method of preparing unit test cases ahead of development or design. The unit test cases effectively form the design of the code created.
This is different to traditional techniques such as the [waterfall method] or [V-Model]. This is because in these models the design is done up front, and test cases and code are driven by this design.
In TDD, the unit test cases will become the design for the code.
To truly answer this question, we need to break this down into a few sub-headings or bullets, because the list is quite extensive.
Here is a breakdown of these Pros:
Speed of delivery: Once you have the tests laid out, the coding is easier to complete. This is a two-edged sword, as you will see later, because this can also be seen as a gift and a curse.
Fewer Defects: Because the tests are created up front, it is easier to test and eliminate potential defects. This is because the test team will think of the potential errors up front to tests, allowing the dev team an opportunity to cater for these issues up front.
Obviously, you will still find defects, but, if done correctly, it should greatly reduce them.
Efficient Code: Because you are focused on specific test cases, you will have more efficient modular code. Rather than thinking about the application as a whole, you can focus on that more focused modular code.
Easier to Test: Because the test cases are created up fron and form the design, you have a clear plan of tests before the application is created. It means that the testing process should be straight forward.
All the test conditions should be in place and ready to go as soon as the code base is available.
Here is a breakdown of these Cons:
Slows down development: This was the “Gift & Curse” that I mentioned earlier. From a project perspective the TDD method will help efficiency and speed. However, the actual development phase cannot start until the test are laid out.
It is still beneficial doing it this way, but just understand that there is a hit on your development start date using this method.
Require Highly skilled unit Testers: Because the testing is the center of this method, it is actually the tests that have to be high quality. What does this mean? Well, for example, you need to consider every potential test condition, before development.
A novice unit tester with little experience may be inclined to create a list of “happy path” tests, that may skim over many potential issues that the code can introduce.
Therefore an experienced unit tester with not only theory of the method, but experience of working in similar projects and understanding of the actual software that is being created.
For example, if you are building a new CRM system for the energy market. You will not only need a skilled TDD unit tester/developer, but one that has knowledge of the energy market to understand the service requests, market messages, etc. Are you with me?
Harder to apply to existing projects: If you have an existing, legacy system. The chances are you have processes in place already to test and develop it.
It is quite hard to transition from an older method, such as the [v-model] for example, to TDD. Not only will you need to change your processes, you will need to re-skill your staff, or bring in new staff to cover this. All of which will incur challenges and cost.
There are three key stages to TDD: Red, Green and Refactor. Each stage is as follows:
Red Phase: This is where the tests are created ahead of development, and arguably one of the most important stages in the process. If you miss something here, you will have a tough time getting the project to be successful.
Green Phase: This is where the code is written to address the tests created in the red phase. This is an ultra-focused process because the heavy lifting should have been done in the first stage.
Refactor Phase: This is the stage to tidy up the code. Such as making sure it is readable and maintainable. The green phase really focussed on making sure the code covered the test cases, which effectively have become the requirements.
How is TDD different to ATDD and BDD? TDD, as discussed is focussed on creating tests up front. BDD or “Behaviour Driven Development” is, as the name suggests, a behaviour related methodology. It focuses on “Is this really what we should be testing?” as a continual question.
The BDD method makes sure that user stories that are built reflect actual business functionality. Whereas TDD is focussed at a unit test level, largely focused on code.
ATDD stands for Acceptance Test-Driven Development, it is highly collaborative methodology that encourages interaction from developers, users and testers. An acceptance test is created, from a users perspective and the code has to deliver based on this acceptance criteria.
The biggest difference between TDD and these methodologies is the stakeholders involved. TDD is largely a developer driven methodology without the interaction with other stakeholders.
How is TDD different to the traditional development process? With the traditional development process, the coding is done up front based on some ridged requirements, usually compiled by a Business Analyst (BA).
In parallel the test team would typically write test cases, to test that the code matches the business requirements. With the developers writing unit tests after the code is complete, to check that the code is fit for purpose and ready for the system test team to start their test phase.
With TDD however, this is flipped on its head. With the developers writing their unit tests up front, then coding. Once the code is done, it will be “Tested” to see if fails the pre-written test. Nowadays these are typically automated tests.
So there is a distinct difference here.
Is TDD Good for you? The decision to use TDD is quite subjective. As discussed it can help to make more efficient code, cut costs and focussed development iterations. Another benefit that has not been addressed earlier is the fast feedback to the developer to improve their code and help for a better quality release.
As a tester, TDD can help because each code unit will have a documented use case. Making it a lot easier to design and plan a suite of tests. With Agile testing it can sometimes be difficult to test, when you are asked “Test This”, only to discover that their os no documentation and your project manager presents you to a “moody” developer to get the “requirements”.
This method will help to give you some documented conditions and push back if you are challenged on how this test passed, etc. All in all it will benefit everyone on that basis.