Test-Driven Development Study Notes

Test-driven development is an analytical method that forces programmers to think carefully about what to do and what not to do, rather than how to implement it. In particular, the exceptions are written in the language of the program. This is like a clear formal contract between the programmer's task and the programmer.

Test-driven development is a design method. Unit Test is a program, not an idea. The programmer must clearly define the program interface before writing its Unit Test. At this time, programmers do not know and do not need to know how the specific logic is implemented. Programmers only need to consider the Class interfaces and functions.

Test-driven development is a quality control method.

Test-driven development is a reconstruction and optimization method.

Test-driven development refers to the process of quantifying demand analysis, design, and quality control.

Advantages of test-driven development:

The foundation of happy work is to have confidence in yourself and the fruits of your work. The test assembly provided by test-driven development can serve as a source of confidence.

Using TDD in development can effectively avoid over-design and development. If programmers do not want to use a Method, most of the Methdo is not required.

For programmers, by running Unit Test and Function Test, they can clearly know that their code is work every day after work.

For the management layer, the quality and development progress of the project are clearly known early every morning through the results of the overnight Test.

Development teams have reduced communication costs and increased mutual trust.

Sample is provided for those who use your results, whether it is to use your source code or directly reuse the build you provide.

The system can be released together with a detailed test set to facilitate modification and expansion of future versions of the program.

TDD gives us confidence, let us solve the problem today, tomorrow's problem will be solved tomorrow, and today cannot solve tomorrow's problem, because tomorrow's problem has not appeared today (without TestCase ), I will not write any code unless I have a TestCase; I do not have to worry about today's problems tomorrow.

Code is in high quality most of the time.

In fact, the development efficiency is improved.

More bugs are found than traditional testing methods.

This avoids headaches and saves debugging time.

How does one implement test-driven development ??

Before developing a new feature:

First determine what you want to do (not how to do it !!) For example, to add a user to a forum, we need a method to add a user:

Public void addAccount (Account account)

Of course, this includes successfully adding a user (inserting a record in the database) and returning a user's existing message if the same user already exists.

Then, write the Unit Test example (Unit Test) for this function to overwrite what this method does. So we have at least two test examples:

Test Case 1: Add a user after the Test is successful.

Test Case 2: add an existing user to the Test.

Test other edge conditions:

Test Case 3: The input Account object is NULL.

Write the Production code:

We know exactly what this code should do. Because we have another piece of code there, with a clear table name, the Contracts of this Code.

Run Unit Test

If it succeeds, you have completed your task well.

If the patch Code fails, the patch code will pass the Unit Test.

Notes