Test-Drive Development Approach for Agile Software Development

Now, people are often talking about agile development.

What is Agile Development?

Agile development is a software development capability that responds to rapidly changing needs. Their specific names, concepts, processes, and terminology vary. Compared to “non-agile,” they emphasize close collaboration between programmers’ teams and business experts, face-to-face communication (considered more effective than written documentation), and frequently deliver new software releases, small and self-organizing teams for small and valuable features writing, and team organization approaches that adapt to changing needs, with a greater focus on the role of people in software development.

However, there are several similar versions of TDD agile development methods, such as TDD: BDD, DDD and ATDD. Let me briefly introduce these methods before introducing TDD in detail:

TDD: Test-Driven Development

Test Driven Development (TDD) is a software development process, which relies on transforming software requirements into test cases before software is fully developed, and tracking all software development by repeatedly testing software for all test cases. This is the opposite of developing software first and then creating test cases. Some popular models support TDD very well, such as MVC and MVP.

BDD: Behavior Driven Development (Behavior Driven Development)

Behavior driven development (BDD) is also an agile software development process. It encourages collaboration among developers, quality assurance testers, and customer representatives in software projects. It encourages teams to use conversations and concrete examples to formalize a common understanding of how the application should work. It comes from test driven development (TDD).

ATDD: Acceptance Test Driven Development

In order to promote the realization of functional code through unit test cases, the team needs to define expected quality standards and acceptance rules, and promote developers’ TDD practice and testers’ performance through a clear and consistent acceptance test plan (including a series of test scenarios). For developers, it emphasizes how to implement the system and how to test it.

DDD: Domain Drive Design

DDD refers to domain-driven design, i.e. domain-driven development. DDD is actually built on this foundation because it focuses on service layer design, focuses on business implementation, combines analytics and design, and no longer keeps it in a divided state, in order to correctly and comprehensively implement customer needs and build a model of business scalability.

TDD implementation plan

Through testing to promote the entire development, but test-driven development is not just a simple test work, but a process of quantifying requirements analysis, design, and quality control.

Development principles

Write the test code first, and then write the code for the function.

1. Write test code according to the requirements document, not to realize the function;
2. Don’t want to be fat with one bite. When testing large functional blocks, you should first split them into smaller functional blocks for testing;
3. Remember not to write code to complete the function, use the simplest possible code to implement the function;
4. If the requirements can be tested, write test code, and give up those that cannot be tested or feel that they do not need to be tested;
5. Before changing/adding any function code, you must first think about whether you want to change/add test cases;
6. Function/test code, unreasonable structure, duplicate code, etc., refactor in time after the test passes.

TDD development process

1. Analyze and determine a target test scenario;
2. Add a unit test to verify the input and output of the test scenario;
3. Run the test and get the failed test result;
4. Write the simplest function code to pass the test;
5. Run the test again and see that the test passes;
6. Carry out code refactoring, including functional code and unit test code;
7. Repeat the above steps until the development is completed.

Benefits of TDD

1. Reduce the burden on developers. Through a clear process, let us focus on only one point at a time, and the burden of thinking is less.
2. The protection net. Covering complete unit testing provides a protective net for product code, making it easy to meet changes in requirements or improve code design. So if your project requirements are stable, done at once, and there are no subsequent changes, the benefits of TDD are less.
3. Clarify requirements in advance. Writing tests first can help us think about the requirements and clarify the details of the requirements in advance, rather than discovering unclear requirements only halfway through the code.
4. Quick feedback. A lot of people say that when TDD, my code volume increases, so development efficiency decreases. However, if you don’t have unit tests, you have to test them manually, you spend a lot of time preparing data, launching apps, modifying interfaces, and so on, and feedback is slow. To be precise, quick feedback is a benefit of unit testing.