Test-Driven Development Notes [beginner]

[Basic steps and procedures]

1. perform initial requirement analysis based on the problem, and extract the initial and incomplete [To-Do] list;

2. Select a [To-Do] in the [To-Do] list and write the corresponding test;

3. Run the test and fail to pass the test;

4. Make the simplest improvement and run the test to make it pass;

5. refactor the code, run the test, and pass the test in a small step;

6. Jump to [2 ].



Key elements]

1. [To-Do] list: the task to be completed, the current task to be done, and the mark to be completed.

2. The valid tive test for the to-do chosen: Write an effective test for the to-do list;

3. The simplest code for passing test: Use the simplest method to pass the test;

4. Code refactoring: through code refactoring, it conforms to a good software design concept and passes the test.
 

[Core concept]

1. First test then code: Development habits of [first test and then Code]

This is the most important purpose of test-driven development.

2. teensy-weensy steps: the forward strategy of [one small step, one small step, and one small step]

① The strategy of [one small step, one small step, and one whole zero] is always used to ensure even forward, without greedy for local speed, but for the global pace of forward.

② Teensy-weensy steps can be used to resolve complicated development and reconstruction processes into simple and easy-to-implement steps.


[Core concepts]

1. The main purpose of test-driven development is to keep the code under the supervision of testing.

When performing code reconstruction and maintenance, you can clearly see the impact of new code on the original system and be confident in refactoring and maintenance.

2. Strategies for [moving forward in one step and one small step to zero:

① It may not always follow the "One step, one small step" approach, but make you [always able] move forward in one small step, and finally reach the end;

② In the concept of test-driven development, a new small test is added. Failure to pass the test and passing the test are all about moving forward to the goal and making progress.

③ If you rush ahead and violate the strategy of one small step and one small step, you will be stuck there when an error occurs and you cannot pass the test.

First make it works, then make it right.



[Basic questions and answers]

1. How to start [TDD ]?

Use traditional problem analysis skills to perform simple and initial requirement analysis and form an initial [To-Do] list;

The [To-Do] list is usually an intuitive understanding of the problem and is incomplete. It will be gradually improved during the [test-encoding-reconstruction] process.

2. What is the first step after the initial "to-do" list?

Start with the first test, instead of writing the first class. It is very important to remember to overcome the inertia of coding before testing.

3. Select the [To-Do] in the [To-Do] list ]?

Usually, you can choose the [To-Do] That is the easiest to implement. Sometimes, you can use intuition, but always follow the principle of [starting from the simplest place.

4. How do I compile a valid test for the selected [To-Do?

① At the beginning, it was always the most intuitive and simple test;

② In the code refactoring stage, the object interface may be changed, so that the test code needs to be reconstructed so that the test still executes the original test function and is more effective at the same time.

5. How can we make simple improvements to pass the test as soon as possible?

① By constructing an empty implementation and a stub method, the test will be compiled as soon as possible, but the function test will fail;

② Use brute-force hard coding and the simplest method that can be thought.

6. How can I refactor the code to make the test pass?

This is the difficulty of test-driven development. Only by mastering the reconstruction technology and software design literacy can we do this step better.

One easy way is to refactor in a small step and run the test immediately after reconstruction.

7. How to mark completion?

When the corresponding test of the selected [To-Do] is passed through code refactoring, It is crossed out from the to-do list; until all [To-Do] on the [To-Do] list is crossed.

8. How to identify what is currently being done?

Mark the selected [To-Do], such as underscores and circles.



[Advanced topics and ideas]

9. How can I ensure that the [To-Do] list fully covers the features and constraints required by the problem?

① When a new requirement is found during the development process, it is added to the to-do list. The requirement analysis of [TDD] is incremental.

② After all [To-Do] is completed, a comprehensive test review should be conducted to ensure that the features and constraints required by the problem are fully covered.

[TDD] instead of eliminating the traditional test phase, it makes the final unit test, integration test, and acceptance test easier and reduces the testing and maintenance costs.

10. How can we ensure that the overall software design [TDD] is good and scalable?

[TDD] does not focus on software design. It introduces software design in the Code reconstruction process, so that the software can reach the [global optimal design] through the incremental [local optimal design ]; this looks like a greedy policy ].

11. In [TDD], how should we deal with the relationship between requirements and testing?

[TDD] converts a requirement to the [To-Do] list and further converts it to a test set.

It converts a project task to a test-centric task. Therefore, you must ensure the effectiveness of the test set,

Otherwise, it makes no sense even if all tests are passed; the test set must be able to fully characterize all requirements.

12. How to deal with the relationship between testing and design in [TDD?

[TDD] does not specify the relationship and sequence between design and testing;

The test code may also need to be restructured to improve the test effect. The reconstruction of the test code will lead to the reconstruction and change of the product code.

Testing-driven development requires a lot of refactoring technologies. But introducing good software design in the refactoring process requires a high degree of software design.

13. How to define [one small step] in [TDD ]?

[TDD] does not mean that the above steps must be performed mechanically. These steps are designed only for beginners;

The iteration steps and pace can be changed according to your actual design and programming level.

14. [TDD] What scenarios are TDD applicable? How can we apply it to large projects?

① [TDD] is fully competent for small projects;

② For large projects, developers can use [TDD] to complete their module tasks;

③ [TDD] How is the test, coding, and design work separated and divided?

15. [TDD] How can we ensure that testing is effective?

Test management is a key aspect of [TDD]. If the test is not effective, the Code cannot implement the required functions.

The requirement must be effectively converted to a test so that the test can fully characterize the requirement.

 

[Exception]

① Sometimes, you need to adopt a [Back-to-go] strategy to properly reduce the design quality and roll back to the status of repeated code,

Find a breakthrough through another reconstruction.

② With detailed tests and reconstructed clean code, we usually only need to perform experiments to verify whether the new ideas are feasible,

You don't need to worry about reasoning about system behavior. You are afraid that restructuring will damage the original system.

③ In some key points, the speed should be slowed down, and the design ideas should be carefully considered to write effective tests so that the subsequent system construction can be well scalable;

Design considerations should be carried out before testing. At this time, you may need a wealth of practical design experience to guide you in making better decisions.

④ In a very small number of cases, it will still rush forward when the red light is on, and write a new test;

⑤ When writing methods for debugging (such as tostring) and helper classes, you can directly participate in the refactoring process without writing tests.

Test-Driven Development Notes [beginner]