Agile Development Reading notes (ii)

Test-driven development

Extreme Programming (EXtreme Programming, abbreviated XP) is one of the most famous agile methods. It consists of a series of simple but interdependent times. These practices combine to form a whole that is better than a partial combination. One of the most important is the practice of TDD (test-driven development method), which is also currently being given special attention.

In a test-driven development approach, all code is written to allow failed unit tests to pass. Start by writing a unit test, because the functionality it is testing is still there, so it will fail to run. Then write the code to make the test pass.

The pace of change between writing test cases and code is fast, basically a few minutes or so. Test cases and code evolve together, where the test cases guide the writing of the code in a gradual manner. As a result, a very complete set of test cases is developed together with the code.

The rough test can be divided into unit test and acceptance test. Unit testing is a white-box test used to validate individual mechanisms in the system.

Unit tests are used to verify that small constituent units of a system should work the way they want, but they do not validate that the system works as a whole. Therefore, unit testing is necessary, but not sufficient.

Acceptance testing is a black-box test that validates the system to meet customer needs. Acceptance testing is written by people who do not understand the internal mechanisms of the system. The acceptance test is a program and is therefore operational. Acceptance testing is typically written by using a scripting language that is created specifically for customers of the application. Just as unit tests are compiled and run as documents about the internal structure of the system, acceptance testing is a compiled, executed document about the system's characteristics.

Writing unit tests before you write your code brings four obvious benefits:

1, first write the test so that each function in the program has a test to verify the correctness of its operation. This provides support for future development, allowing us to make changes to the program more freely, because tests can tell us that the program still has the correct behavior.

2. Writing tests first forces us to look at the program that we are going to write from the vantage point of the program caller. In this way, we will focus on the function of the program, and directly focus on its interface, we can also design a convenient software to invoke.

3. Writing tests first compels us to design the program as testable. In order to design for easy invocation and testability, the program must be decoupled from its surrounding environment. This first writing tests forces us to release the coupling in the software. The principle of object-oriented design has a great help in this decoupling.

4. Another important effect of writing tests first is that tests can be used as an invaluable form of documentation. Testing is like a set of examples that help other programmers understand how to use code. This document is compiled and can be run. It stays up to date. It doesn't lie.

The behavior of first writing acceptance tests has far-reaching implications for the architecture of the system. In order to make the system testability, the system must be decoupled at a high level of system architecture. Just as unit testing can motivate you to make good design decisions in small ways, acceptance testing can motivate you to make good system architecture decisions in large areas.

Agile Development Reading notes (ii)