Three military rules of TDD

Over the years, I like to use 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 result in a failed unit test 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) must keep the system running. The interval between running tests should be in seconds or minutes, even if it is only 10 minutes, it is too long.

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

Today, many Programmers think, whenever 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. It will make me unable to think, design, and disrupt my thinking ." However, imagine what would happen when you enter a room where people work in this way? You can select a time and find someone at will. One minute ago, all their code ran through.

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?

More than that. If you use this method, you will produce several tests every hour. There will be more than a dozen tests every day, and 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. If we have these tests, we will be at a loss in terms of code changes. If we see 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.

More than that. 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 help document with 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, completely unambiguous design documents that are fairly formal and even executable, and will not be separated from the product code.

More than that. If you have experienced adding unit tests to a system that can work, you will find that it is not fun at all. You may find that if you want to run the test, you must either change part of the design in the system or resort to test fraud. This is 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 don't want this record to be deleted, but there is 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 anything that works very well but has basic 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 no longer endure the practice of first dividing a group of modules and then integrating them and enabling them to 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!