Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to understand TDD". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand TDD.

At present, many domestic software developers have a vague understanding of TDD, and most people do not clearly and consciously implement TDD, so many people have different understandings.

One of the most classic understanding is based on a unit of code, using Mock and other technologies to write unit tests, and then use this unit test to drive development, or to help regression testing after refactoring and modification. Now most of the voices against TDD are based on this understanding, such as:

The time limit is tight, the time is short, and it is a waste of time to write TDD.

Business requirements are changing so fast that it is too late to modify functions, and there is no time to write TDD

Writing TDD requires very high quality of developers, and ordinary developers can't write.

The biggest problem with TDD implementation is that most programmers do not know how to "write test cases" and "refactoring".

Due to the extensive use of Mock and Stub technology, UT has no way to test the integrated function, which is of little effect on testing business value.

.

To sum up, the main reasons for technicians to reject TDD are difficulty, heavy workload, heavy use of Mock, which makes it difficult to test business value, and so on.

These understandings are mainly based on one-sided understanding and practice, and in my understanding, the core of TDD is to write tests first and use it to help developers drive software development.

The first is to write tests first. The tests here are not just unit tests, nor do you have to use mock and stub to do tests. The test here refers to the software test itself, which can be a unit test based on code units, a functional test based on business requirements, or an acceptance test based on specific acceptance conditions.

The second is to help developers, mainly to help developers understand the functional requirements and acceptance conditions of the software, to help them think and design code, so as to achieve the purpose of driving development, so TDD includes two parts: ATDD and UTDD.

ATDD (Acceptance Test Driven Development): acceptance-driven test development, first BA or QA write acceptance test cases, then Dev understands the requirements and acceptance conditions through acceptance tests, and writes implementation code until the acceptance test cases pass.

Due to the variety of acceptance methods and types, ATDD actually includes various practical methods, such as BDD (Behavior Driven Development), EDD (Example Driven Development), FDD (Feature Driven Development), CDCD (Consumer Driven Contract Development) and so on.

For example, take the behavior of the software as the acceptance standard, this is if BDD; takes specific instance data as the acceptance standard, this is if EDD; uses Web Service API consumers to put forward API contracts to drive API providers to develop API, this is CDCD and so on. Therefore, the specific implementation of ATDD needs to be combined with the actual situation of the project to select the appropriate acceptance testing methods and types.

UTDD (Unit Test Driven Development): unit-driven test development, first Dev writing unit test cases, and then writing implementation code until the unit test passes. This is what many people now call TDD, practical TDD, favorite TDD, complaining TDD, but it is only part of the real TDD.

TDD Pyramid

Let's take a look at David's "TDD is dead." Long live testing ", he mainly believes that TDD uses a lot of mock, which makes it impossible to test the function of the software after connecting to the database, and thus unable to test its business value.

Second, he suggested that "Long live testing" should be used, but he did not say whether the test should be written before or after writing the code, and whether it would be used as a customer acceptance standard for the software. If he doesn't, he just uses "Long live testing" for regression testing; if he does, he also uses ATDD and therefore TDD.

So his understanding of TDD is still narrow, thinking that TDD is just UTDD, which led him to write this article to criticize TDD. It is possible that he has used ATDD, that is, TDD, in his real work.

Finally, let's take a look at Kent Beck, Martin Fowler, David about Is TDD Dead? I think what they said is reasonable and reasonable. The reason is that their backgrounds and industries are different, and the appropriate test-driven methods should be chosen for different industries and different backgrounds (may be different).

First, let's take a look at Kent Beck, who works at Facebook and has published many books, which can be positioned as a software thinker working for a large IT company. The second is David, a standard European handsome guy, one of the creators of ROR, the founder and CTO,Basecamp of Basecamp is a small software company with only a few dozen people, so he can be positioned as an entrepreneur and technician.

Kent Beck's company develops large-scale complex business software (Facebook platform), which requires a large number of people (tens or even hundreds) to develop and maintain it for a long time (several years). Small and medium-sized enterprise software (such as CRM) developed by DHH has a general amount of code and needs to be developed and maintained quickly (a few months) and with a small number of people (a few to a dozen).

In the case of relatively sufficient money and human resources and relatively abundant time, Kent Beck pursues code quality, good cooperation of a large number of people and stable platform.

However, DHH seeks to maximize customer business value with relatively little money and human resources, so that a small number of people can quickly develop software and sell it to customers to make money.

So in Kent Beck's environment, unit testing (UTDD) is very valuable; in DHH's environment, functional testing or ATDD is more appropriate.

Many people's narrow understanding of TDD in China also stems from a lot of Chinese materials on the Internet. Baidu Encyclopedia's explanation of TDD is one of them:

The principle of TDD is to write the unit test case code before developing the functional code, and the test code determines what product code needs to be written. Although TDD is the core practice of agile methods, it can be applied not only to XP (Extreme Programming), but also to other development methods and processes.

And the information on many sites abroad is a correct understanding of TDD, such as the following figure is an Agile questionnaire. From the words "We take a test-driven development (TDD) approach" and "We take a TDD approach at the requirements level", we can find that their understanding of TDD includes UTDD and ATDD.

TDD is not a silver bullet, do not expect it to solve any problem, whether it is UTDD, EDD or BDD, according to the actual situation of your project, such as capital, human resources, time, organizational structure, etc., reasonable choice.

At this point, I believe you have a deeper understanding of "how to understand TDD", might as well come to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.