31 Jul

Test Driven Development as an Agile best practice

Agile Software Development Methods are nowadays widespread. New approaches such as continuous delivery and continuous deployment call into question the traditional software development methods and practices.

In order to be competitive, products and projects have shorter lead times and delivery with minimal costs.

How to deal with such key elements without compromising software quality?

Modern Software Testing approaches and methodologies are being developed to satisfy the customers’ need for speed and quality.

In particular, Test Driven Development (TDD) is a software development process that brings more agility to the process. It is based on the repetition of a very short development cycle, in which developers “Only ever write code to fix a failing test.”

It consists of writing a test first, then writing a code to make the test pass.

Specifically, there are three activities tightly interrelated:

  • Developing test script, (writing unit tests), it consists of writing a test that defines a function included in the Use Case. In this phase, the developer can focus on the requirements before writing the code,
  • Developing code, it consists of writing a code to pass the test. Such activity provides a quick feedback between codes and unit tests. The developer cannot write codes outside the functionality that the test checks,
  • Refining (refactoring), this phase is critical for the success of TDD. Developers refine the code without altering the functionality, to improve software quality and design.

Test Driven Development follows the agile method of building software in iterations to achieve a clean, simple designs and code.

Benefits of TDD:

  • Identify bugs early in the development cycle,
  • If a defect is identified and the relevant test is written, then the effectiveness of its regression test will be increased,
  • Less debugging effort as the code is entirely tested,
  • Avoid proceeding by trial and error,
  • Refactoring helps to improve software design and code structure,
  • New features can be easily introduced,
  • If the tests are executed in the development phase, the pre-release test will be remarkably shorter;

Limits:

  • Difficult to implement if the Use Cases are lacking or the interaction between testers and developers is low,
  • Each developer should have testing skills and know techniques and technologies to write Unit Tests,
  • It takes a lot of time and effort and may create a sense of frustration;

Application example:

Text: Developing a module to test if a string added to a Textbox is greater than 0 but less than 10.

Testing:

  • The string length between 0 and 10, limits excluded.

Step 1

The tester in charge writes the unit test to ensure that the correct string length is between 0 and 10, limits excluded.

Under the Use Case, the tester in charge will write the following the Test Case:

Step 2

The developer writes the following code:

Performing the test, the result will be FAILURE! Because the developer added a bug. Such event is outside specifications but gives the possibility to validate also the 0 and 10 limits, failing the first and third cases. The developer immediately gets the necessary feedback to correct the defect writing the following code:

Performing the test, the result will be PASSED!, in this case, it is possible to proceed to the next step, the refactoring.

Step 3

In this step, the code is made readable through refactoring, the complexity of this step depends on the written code, in this case:

Further iterations

In this example, all Use Case requirements are met within a single cycle, and through refactoring, it was possible to clean and refine the code.

Any other additional feature the customer may require can be included by simply developing a new code to meet the new requirement, and along with the new coding activity, the tester in charge would develop the new test case and include the new code to make the test pass.

 

Share this