Test-driven development

Recently read a few articles about test-driven development, briefly summarize the following:

The basic idea of TDD is to drive the entire development through testing, but test-driven development is not just a test effort, but a process of quantifying requirements analysis, design, and quality control. To put it bluntly, write the test code before you develop the functional code, and then write only the function code that passes the test code to drive the entire development process with testing.

1. Before starting the work, a discussion by the business analyst, Tester, and developer to agree on acceptance criteria and to form a record will prevent testing and developers from understanding inconsistencies.

2. Make a todo-list out of a specific requirement to remind us of what needs to be done, it will keep us focused, and colleagues can tell us when we can finish. If we think of other tests we want to do, we'll add a list.

3. Add a test and write a test case according to the requirements

4. Run all the test programs (sometimes only one or a part of them) and fail, because the classes, functions, and so on, which are related to the test, will fail.

5. Make some minor changes, these changes actually only write the code that allows the test to pass (no need to implement specific functional code details), at this point, as soon as possible to let the test program run, for the second can be used in the program to use some non-clean methods.

6. Run all the tests and pass all

7. Refactor the code to eliminate repetitive design and optimize the design structure

TDD principles

Independent testing: test of different code should be independent of each other, a class corresponding to a test class (for C code or C + + global function, a file corresponding to a test file), a function corresponding to a test function. Use cases should also be independent, and each use case cannot use the result data of other use cases, and the results cannot depend on the order of use case execution. A role: The development process involves a variety of tasks, such as writing test code, writing product code, code refactoring, and so on. When doing a different job, focus on the current role and don't think too much about other details.

Test List (to-do list previously established): The function points of the code can be many, and the requirements may be a succession of, any stage want to add functionality, the relevant function points should be added to the test list, and then continue to work at hand to avoid omissions.

Test-driven: The use of testing to drive development is at the heart of TDD. To implement a function, to write a class or a function, you should first write the test code, clarify the class, how the function is used, how to test, and then design, code it.

Write the assertion first: When writing the test code, you should first write an assertion statement that determines the function of the code, and then write the necessary auxiliary statements.

Testability: Product code design, development should be as much as possible to improve testability. The function of each code unit should be relatively simple, "each house in front of the snow", each class, each function should only do what it should do, do not make a hodgepodge. In particular, to add new features, do not for the sake of a moment, casually in the original code added functionality, for C + + programming, should consider using subclasses, inheritance, overloading and other OO methods.

Timely reconstruction: Unreasonable structure, repetition and other "taste" bad code, after the test passed, should be timely reconstruction.

Small steps forward: software development is a very complex task, and small steps are a good way to reduce complexity. The more complex the software, the smaller the pace should be, before you start the next job, make sure that the functions you have completed are correctly executed.

Kent Beck. Test-driven Development (Chinese version)

This article is from the "Diannaowa" blog, make sure to keep this source http://diannaowa.blog.51cto.com/3219919/1671989

Test-driven development