Hello, I'm Weiki and welcome to ape java.
Have you heard or heard about TDD? Do you know what TDD is? Do you know how it works? Today we will talk about TDD.
I once read a post on the personal blog of Martin Fowler (Martin Fowler) about the discussion of Is TDD Dead by Kent Beck, David, and Martin Fowler and David
's TDD is dead. Long live testing .
Some introductions of several authors
Martin Fowler(马丁·福勒)，出生于英格兰，后移居美国，像微服务，
DSL(领域设计语)，统一建模语言等思想都是出自他，大家有兴趣可以看看他的个人博客：
https://martinfowler.com/，上面有很多优秀的博文，思想值得我们拜读。
Kent Beck：美国人，JUnit单元测试框架作者之一，敏捷开发的开创者之一
David Heinemeier Hansson：丹麦人，Ruby语言创始人
What is TDD?
TDD comes from Extreme Programming. Baidu Encyclopedia explains it as follows:
TDD is the English abbreviation of Test-Driven Development. It is a core practice and technology in agile development, and it is also a design methodology. The principle of TDD is to write unit test case code before developing functional code, and the test code determines what product code needs to be written. Although TDD is the core practice of agile methods
, it is not only applicable to XP (Extreme Programming), but also applicable to other development methods and processes.
This explanation is relatively one-sided. In fact, TDD consists of two parts: ATDD and UTDD
ATDD
Acceptance Test Driven Development, acceptance-driven development. For example, QA (Quality Assurance) will write test cases, and then review them with PM (Product Manager) and RD (Technical Development). This process can help RD better understand business requirements and acceptance conditions, so that they can be written later with acceptance goals until acceptance test cases pass.
There are many ways of testing, such as BDD (functional testing), white box testing, integration testing, etc. Different testing methods are used according to different scenarios in order to achieve acceptance.
UTDD
Unit Test Driven Development, unit test driven development, RD first writes unit test cases, and then writes the implementation code until the unit test passes.
About ATDD and UTDD On the official website of Thoughtworks, there is an abstract picture, you can refer to the following:
The following is an xmind diagram
How to do TDD well?
Before analyzing the TDD solution, let's solve a problem: test-driven development, where does the whole process start?
Answer: test
So, where does testing begin?
Answer: demand.
What is the purpose of testing if there are no requirements? Therefore, requirements are the source of testing; in the face of huge requirements, how to test? The method is to decompose the requirements into small tasks that can be tested one by one.
So test-driven development starts with task decomposition.
The following are two pictures from Thoughtworks official website to express the whole process of TDD.
TDD implementation - schematic diagram of steps:
TDD Implementation-Collaboration Diagram:
I personally feel that TDD can be implemented from both strategic and tactical perspectives, just like DDD.
strategic angle
From a strategic perspective, it is more of a methodology at the ideological level, which can guide us to implement TDD in a better way.
The following describes the entire life cycle of a requirement from proposal to launch:
When a new request is received,
- First of all, PM will have a demand review, which will explain the business background, explain the problems to be solved and what goals to achieve;
- Then, RD will conduct business decomposition, upstream and downstream communication according to the demand review, and then do technical detailed design and technical seminars;
- Then, QA will write test cases and use case reviews in combination with requirements review and RD's technical lectures, and check the acceptance goals and launch time from multiple parties;
- Then, RD will do architecture design, code design, code writing, and code testing; QA will do testing-related work, such as: use case design, test scripts, etc.;
- Finally, RD development is completed & tested, QA conducts testing until it is approved, and PM conducts final acceptance until the code goes online;
The entire process embodies the strategic thinking of TDD, and the entire life cycle provides certain process specifications for ATDD and UTDD.
tactical angle
From a tactical point of view, it is more explained from a technical level. From a strategic point of view, we have proposed a methodology for how to implement each step in the process. This is the tactical point of view.
- For example: Decomposition of requirements, according to which dimension should be decomposed, whether it should be divided according to domain or process, and how large a task should be decomposed into is reasonable.
- For example: architecture design, what architecture idea to use, is it a hexagonal architecture or an onion architecture.
- For example: code design, what design pattern needs to be used, adapter pattern or factory pattern.
- For example: code writing, what data structures and algorithms need to be used, and how to make the code more reusable.
- For example: testing, how to design test cases, what testing framework to choose, how to automate testing
The implementation of TDD has a classic trilogy: red-green-refactoring. Both ATDD and UTDD can be implemented in accordance with this three-step process. The schematic diagram of the trilogy is as follows:
In many testing frameworks, red means that the test has not passed, and green means that the test has passed. To turn red into green requires constant refactoring.
Therefore, we can understand: in order to write tests, we first "drive" us to understand the business, decompose the requirements into individual tasks, and then "drive" us to give a testable design, and in the specific stage of writing code , and will "drive" the code we keep improving and writing. Putting these things together, we are really "driving" development with tests.
With the guidance of strategy and tactics, the most important thing is to cultivate the ability to support these strategies. Implementing TDD ideally requires the ability to:
- Test the ability to move forward (shift left)
- Analysis of business and technical requirements and task splitting capabilities
- Test case design ability
- Automated Test Development
- Capability code refactoring
- Ability to continuously improve
misunderstanding
Myth 1
In the understanding of many programmers, UTDD is TDD, and TDD is UTDD, so that we ignore business-oriented or test-oriented ATDD. Therefore, the scope of TDD is virtually narrowed. A benchmarking table for ATDD and UTDD is given below
Myth 2
TDD is to write the test before writing the code, the reason has been analyzed in the TDD tactics section.
Is TDD really "dead"?
As the article begins Is TDD Dead?
The answer is: NO, and TDD is still doing well at present. Many companies have been practicing it, but they have not specifically emphasized that it belongs to the category of TDD. At the same time, TDD is not a silver bullet, and it is impossible to solve any problems in actual work. What we have to do is to continuously learn, compare and summarize, and implement it according to actual business needs. After all, the best is the right one.
Do programmers really need to master TDD?
It is necessary, we don’t have to emphasize the concept of TDD, but TDD is to ensure the code quality of programmers, and code quality is the bottom line of programmers.
UTDD can help programmers to write unit tests better and more systematically; ATDD , can allow programmers to better understand the business, and ensure the robustness of the code to the business through a deeper understanding of the business.
references
Thoughtworks official website TDD
Book: Java Test Driven Development (Written by Viktor Farcic, translated by Yuan Guozhong)
Agile Software Development (by Robert C. Martin)