TDD-General Principles of test-driven development!

Over the years, I like the following three simple rules to describe test-driven development:

1. Unless this permits failed unit tests to pass, no product code can be written.
2. Only unit tests that can cause failures can be written. (Compilation failure is also a failure)
3. Only product code that can cause a unit test failure can be written.

For any function, you must start by writing unit tests. But by the time principle 2 is reached, you cannot write more content for that unit test. Once the unit test code fails to be compiled or the assertions fail, you must stop and write the Product Code. However, when Principle 3 is reached, you can only write the product code, until the test compilation is successful or the assertions are passed.

If you do not compile or execute something, you cannot write code. Indeed, this is the key. Everything we do (whether writing tests, writing product code, or refactoring), we need to keep the system running. The interval between running tests should be in seconds or minutes. Even 10 minutes is even too long.

For more information, see the article "kata" in bowling games.

At present, many Programmers think every time they hear this technology for the first time: "This is too stupid !" "This will slow me down. This is a waste of time and energy, so that I cannot think, design, and it will disrupt my thinking ." However, imagine what happens when you walk into a room where people work in this way. All their code ran away one minute ago.

Let me repeat it again: Everybody's Code ran a minute ago! No matter who you are looking for or when you are looking,All their code ran away one minute ago!

If all your code runs smoothly from start to end, how long will it take you to use the debugger? The answer is, it won't be too frequent. Just a few clicks on ^ Z, you can easily restore the code to the running state, and then try again to write the code for the past few minutes. If you do not debug it frequently, how much time will it save? How much time do you spend debugging? How long will it take you to fix these bugs once you have debugged them? What if you can greatly reduce the time?

This is not just a benefit. If you use this method, you will produce several tests every hour. There will be more than a dozen tests every day. There will be several hundred tests every month. After one year, you can write thousands of tests. You can keep these tests and run them whenever you want! When will they be run? Anytime! Run them as long as you make changes!

Some codes are messy, but why don't we clean them up? We are worried that they will be damaged. But if we have a test, we have reason to be sure that the Code will not be destroyed, or that we can quickly find the destroyed place. With these tests, we are not afraid of code changes. If we see a messy Code or an unclear structure, we can clear it with no worries. With the test, the Code becomes easy to modify again; with the test, the software becomes "soft" again.

This is not just a benefit. If you want to know how to call a specific API, there will be a test to tell you; if you want to know how to create a specific object, there will be a test to tell you. Everything you want to know about this system has a test that can be illustrated. These tests are like small design documents and small code examples that describe the work and usage of the system.

Have you ever integrated a third-party library into your project? You get a thick and exquisite document manual. There is a thin appendix at the end. Which one will you choose to read? Of course, this is an example! That's unit test! They are the most useful part of this document. They are examples of how to use code. They are extremely detailed and unambiguous design documents that are fairly formal and even executable, and will not be separated from the product code.

This is not just a benefit. If you have experienced adding unit tests to a system that can work, you will find that it is not fun. You may find that you either have to change part of the system's design or cheat the test because the system you are trying to test is not based on a testable design. For example, you want to test a function f. However, F calls another function that deletes records from the database. In your test, you do not want this record to be deleted, but you have no way to stop it. Such a system is not based on a testable design.

When you follow the three rules of TDD, all your code can be tested by nature! Another word that can be described as "testable" is "decoupled ". To test a module separately, you must decouple it. Therefore, TDD forces you to decouple these modules. Indeed, if you follow these three rules, you will find that you may be able to perform more decoupling than before. This forces you to create a better, low-coupling design.

After all these benefits are gained, these stupid small rules actually seem less stupid. They are probably some basic and profound principles. Indeed, I have worked as a programmer for nearly 30 years before I started TDD. I don't think anyone has taught me some basic and meaningful programming practices. After all, Thirty Years of Experience means a lot of experience. But when I started using TDD, I was shocked and addicted to the effectiveness of this technology. I will not think about typing a lot of code and expect them to run successfully. I can't bear to break up a group of modules, and then want to integrate them and let them run before next Friday. When I write a program, every decision is driven by this basic requirement that allows the code to be written to be executed again in one minute.

 

:

1. TDD, test-driven development.

2. Kata can be understood as a martial arts trick. For more information, see the translator's previous translation.

Note: This article is based onDeng HuiMr. Zhang personally corrected and gave many pertinent and profound suggestions. The translator would like to thank you!

(Original URL: http://www.butunclebob.com/articles.unclebob.thethreerulesoftdd; Robert C. Martin's english blog: http://www.butunclebob.com/ArticleS.UncleBob)

Note: Robert C. Martin, President of object mentor, is a senior consultant in the field of Object design, pattern, UML, Agile Methodology and extreme programming. He is not only the author of Jolt's award-winning book Agile Software Development: Principles, models and practices (Chinese version) (Agile Software Development (English version, or the author of the bestselling book Designing object-oriented C ++ applications using the booch method. Martin is the editor of pattern development ages of Program Design 3 and more C ++ gems, and has co-authored XP in practice with James Newkirk. He is a well-known speaker at the international conference of programmers and has been an editor of C ++ report for four years.

Trackback: http://tb.blog.csdn.net/TrackBack.aspx? Postid = 1089322