Test Process and Agile Methods
This article describes the importance given to software testing by agile methods. Throughout the article, we discuss why the test is considered the master spring that enables the implementation of many agile principles, as well as because the test is used to reduce the time spent by developers in debugging and fixing defects. In addition, the types of tests run from the perspective of the developer, client, and tester are presented.
Finally we will present the concepts behind the TDD (Test Driven Development).
Test-Driven Development (TDD) has undoubtedly become one of the most popular practices among software developers. The idea is quite simple: write your tests before even writing the production code.
Agile development and software testing
Regardless of the development methodology, one of the most recurrent problems in software development is the high incidence of defects. Defective software causes:
- Development slowness: When a bug / problem is reported, the developer spends a lot of time debugging the code to find out where the bug is, and then to fix it. In addition, the developer who wrote the functionality is not always responsible for correcting their defects. And to make matters worse, companies often assign inexperienced developers to fix the defects;
- Side Effects: Often, correcting a defect introduces other side effects. This is due to several factors, such as: lack of developer experience, lack of architecture in the software, lack of organization in the company’s work processes, tight deadlines, lack of developer attention due to exhaustion due to having to work many nights and weekends in a row, among others;
- High costs: Defects found in production have a correction cost one hundred times (sometimes a thousand times) higher than the defects found during the development cycle. That’s not counting the costs associated with customer dissatisfaction.
Agile methods, in turn, mitigate the risks and challenges associated with a high incidence of defects through testing. Software testing is more than a simple task; in fact, it is the pillar of support that allows the implementation of many principles of agile development, such as:
- Continuous delivery of value software: Testing is the only way to demonstrate whether the software meets customer needs (value software);
- Accept changes: Tests give the team confidence to make changes without fear of causing side effects and instability in the software;
- Involvement of people related to business and development: Tests are described in a common language to all members of the team. In this way, the whole team shares the same understanding of what should be done, the restrictions and the definitions of “Ready”;
- Functional software is the measure of progress: Tests performed often demonstrate progress in developing new functionalities, as well as whether the software still works (no defects have been introduced);
- Technical excellence, good design and simplicity: Tests written before the code induce the developer to think more deeply about the implementation of the functionality, thus making the code simpler and better designed;
- Motivated and confident teams: Successful tests increase motivation (we are doing our job correctly) and team confidence (we are making the right decisions);
- The team reflects on how to be more effective: Testing demonstrates failures in both the code and the work process (and team attitudes), based on the lessons learned during fault correction, the team adjusts and optimizes their behavior accordingly.
In the agile perspective, the test is a parallel task and intrinsic to all stages of development, it is a task closely linked to the act of programming. In the agile methodology known as Extreme Programming (XP), for example, the test guides the development. Through the practice called TDD (Test-Driven Development), the developer writes the test code before writing the code that implements the functionality. In this philosophy, the developer is induced to first think about the rules and constraints of the functionality to then map those rules and constraints on (unitary) tests. Then the developer writes the code of the functionality in order to meet the expected behavior that is determined by the tests. According to Kent Beck, creator and disseminator of Extreme Programming (XP), when the programmer reaches the level of love writing tests, it means that the programmer has become Test Infected.
TDD – Test Driven Development
Basically the Test Driven Development (also called TDD) is based on small iteration cycles of tests and development tasks, where for each system functionality a test is created before. This new test created initially fails, since we do not yet have the implementation of the functionality in question, and then we implemented the functionality to make the test pass! That simple!
However, we can not just write another test just because we already have a successful test. This functionality needs to be refactored to achieve the software development best practices reviews. These best practices will ensure software with cleaner, more cohesive and less coupled code.
Development Cycles in TDD
The TDD Cycle is simple and can be summarized in three phases.
Red, Green, Refactor. That is:
- We wrote a test that initially does not pass (Red)
- We’ve added a new system functionality
- We make the Test pass (Green)
- Refactor the new feature code (Refactoring)
- We wrote the next test
Advantages of using TDD
This technique offers many advantages to the software development process:
- Writing tests prior to implementation prompts the developer to seek more details about the features and rules associated with the story;
- When we plan the test before the development we are somehow validating the concepts of the feature that will be developed, often at this time we identify problems that would only be identified in future phases of the development cycle, and in software development when we identify problems early on we reduce the cost caused by impacts and rework.
- Writing tests before implementation is a great way to clearly express the intentions of what each unit should do, and as a consequence, tests serve as documentation of the expected behavior of each unit;
- Writing tests before deployment requires the developer to write units that are simpler and easier to test. As a consequence, the code has a better design;
- We have, in this type of strategy, quick feedback on the new functionality and on a possible breakdown of other system functionality. So much more security time for refactorings and much more security in adding new features.
Without a doubt, the TDD technique help the developer to eliminate defects in the code, however, the code is not the only source of defects. It is important to emphasize that agile methods offer a very sophisticated set of test techniques to prevent and detect defects in code, requirements, architecture, as well as defects caused by lack of understanding, mistaken assumptions, etc.
Many factors listed above are intrinsically related to Agile Manifesto, that is the basis of Agile Methods. As a result, we can see in the recent years an increase in use this technique.
What’s the difference between doing TDD and writing the test later?
The great responsibility for the increase of internal and external quality is not the TDD, but the automated test, produced before the use of the practice. The common question is just then: What’s the difference between doing TDD and writing the test later?
The developer gets feedback from the test. The difference is precisely in the amount of feedback. When the developer writes the tests only when the implementation of the production code is finished, it spent a lot of time with no return. After all, writing the production code takes time. When practicing TDD, the developer splits his work into small steps. He writes a little test, and implements a piece of functionality. And repeat. With each written test, the developer gains feedback.
The earlier the developer receives feedback, the better. When one has too much code already written, changes can be cumbersome and costly. Conversely, the less written code, the lower the cost of change. And that’s exactly what happens with TDD practitioners: they get feedback at a time when change is still cheap.
Myths related to TDD
Many still do not like the idea of TDD because we have more code to be developed, resulting in more time in developing a feature. But this is wrong. Surely you developer has already fixed a bug in the system, but created two more in place. This happens very often and many companies still only pay developers to fix bugs and even rewrite systems that are terrible to maintain!