Initial knowledge of TDD

TDD, testing-driven development (test driven development) is the program development approach advocated in extreme programming, with its advocacy to write test programs first, and then code to achieve its function name. This article will have a more systematic understanding of TDD.

Base properties

Origin: the 1990s.

Nature: A program development method advocated by extreme programming.

The main idea: Write the test program first, then code to implement its function.

Purpose: Get quick feedback and use the "illustrate the main Line" method to build the program.

Development method

1, wear two hats development way

(1), wearing the implementation of the function of the hat, under the aid of testing, quickly realize its function.

(2), put on the reconstruction of the hat, under the protection of the test, by removing redundant code, improve the code quality.

2. Central idea

The test drives the whole process of driving.

(1), the design of the driver code and the realization of the function.

(2), re-design and reconstruction of driver code.

Test

1. Characteristics

The scope of requirements analysis and detailed design in test-driven development, after the code is basically complete, and these tests become part of the unit test.

2. Key points

Readability is even more important than the production code, clear, concise, enough expressive force.

3. General mode

Construction data-operational data-inspection data

4. Rules to follow

(1), the number of assertions in a single test should be minimized, can quickly and easily understand its conclusions.

(2), each test a concept, that is, each test function to do only one thing.

(3), F.I.R.S.T principle

Fast (first): able to run quickly.

Standalone (Independence): You can run each test individually, which means you can run the test in any order.

Repeatable (Repeat): Tests can pass in any environment.

Automatic validation (spontaneous verification): there should be a Boolean output.

In time (timely): should be written before production code.

Three Laws of TDD

1. You cannot write production code before writing a unit test that cannot be passed.

2, can only write just can't pass the unit test, cannot compile also calculate not pass.

3. You can only write production code that is just enough to pass the current failure test.

In general, write the test before writing the production code, write a test should immediately write its implementation code.

Evaluation

1. Front

(1), can effectively avoid the waste caused by excessive design.

(2), allowing developers to have a more comprehensive perspective of development.

(3) To ensure that all needs are taken care of.

2. Negative

(1), over-focus on use cases and test cases, rather than the design itself.

(2), may cause the unit test coverage is not enough, for example may lack the boundary test.

(3), slow down the development of the actual code speed.

(4), for the GUI, database and Web applications, the construction unit test is difficult, if the forced Construction unit test, but will give the maintenance of additional work.

(5), test case is not so well written, if we develop the test case is to ensure that our code implementation is correct, then, who will ensure that our test case is correct?

My sentiment

Using TDD to complete a small game project, I feel that the way TDD is developed makes me think of another way of thinking, writing tests from the various functional points of the project and testing to implement our production code. Before the completion of a project is a top-down thinking, is standing in a macro perspective, to the overall overview of the project, then the beginning of time to consider a lot, this time the most easily into the details of the misunderstanding, that will be refined to some details difficult to control their own thinking. Now that I'm in touch with TDD, I feel like a bottom-up. Do not consider the global thing, I a small function of a small function of the implementation, was once from the top of the tree to do, now is from the root, each of the roots of the implementation of the top of the layer I add up, and finally a tree, haha ~

Initial knowledge of TDD