Two days ago, a reader left a message to share a "thrilling" development experience, when it was online, there was a bug how to find it, even the boss joined the "find the stubble" action, and finally found that it was actually the assignment written wrong, this small mistake almost caused the company's huge losses, and I was afraid after a while.
He said that although he usually knows that unit testing is very important, people are still very confident in their code in most cases, so they feel that they can't make a big deal without writing. It wasn't until this almost overturn that I understood why the tech bulls repeatedly stressed that pursuing 100% test coverage is a good way to ensure code quality. Testing is guaranteed to minimize errors.
Coincidentally, Xu Hao, CTO of Thoughtworks China, was fascinated by the test for much the same reason as this reader. Although Xu Hao has loved to explore various new technologies since he was a child, he still has some resistance when he first came into contact with TDD (test-driven development), because TDD not only takes each step awkwardly, but also takes longer, and just one example has to be written for a long time, so he does not think that TDD has the possibility of long-term use by the majority of developers.
However, true incense is never absent.
TDD surprised Xu Hao with the first time he started the application after writing the code. He found that there was no bug at all, and the code did not have to be reworked at all. In the past, even if you wrote the code with your own heart, you had to debug at least five or six times to work normally.
Since then, Xu Hao began to force himself to use the TDD method to write all programs, whether it is an application project or a compiler, and seize the opportunity to use TDD. Later, he not only used it himself, but also promoted it within the team and led everyone to use it together.
Gradually, Xu Hao found that the technical level of the team members had increased by a large margin. On the one hand, the reason is that in the process of using TDD, we need to split the requirements and architecture into tasks that are easy to transform into tests, and in the long run, the task decomposition ability and the understanding of the business have been trained. On the other hand, everyone is writing tests more and more efficiently, and in the same development time, you can now get both a set of working code and a set of tests that can be used to locate the problem.
Today, Xu Hao has integrated his own and his team's many years of practical experience in TDD into this "Xu Hao · The geek time column of "70 Talks of TDD Project Development" contains more than 70 lectures, 40+ hours of video demonstrations, and 4 complete project practices. Through it, you can definitely solve the difficult problems such as difficult requirements, difficult task splitting, and TDD difficult landing.
Enter password "xuhao6666" at checkout
Get 40% off for 189
Xu Hao has been dealing with TDD for nearly 20 years, helping large and small teams at home and abroad successfully solve the landing of TDD for many times, and also invented an efficient working method with TDD as the core, with rich experience. Therefore, if you want to solve problems in the use of TDD, or are interested in TDD and want to know more, his column is definitely the first choice.
Joining the learning now, in addition to a hardcore course, also comes with the benefits of a high-quality learning community and Xu Hao's personal review code, which is a good opportunity.
How did Xu Hao explain TDD?
It is precisely because TDD needs to be practiced in different scenarios to master, this column is mainly based on video display, supplemented by graphic explanations. You can experience the difference between using TDD and usual development in specific scenarios.
First of all, Xu Hao will start with a small example of Code Kata level to show the whole process of using TDD development, so that you have an intuitive understanding.
He will then focus on this example and explain the core concepts and methods of TDD in detail, taking you to an in-depth discussion of what tests are in TDD and how TDD drives our development. He will also introduce the entry points where the classical school of TDD (the Chicago School) differs from the London school.
At the end of this section, he will summarize the core advantages of TDD as an engineering approach. If you need to convince your colleagues, friends, and leaders around you to start adopting the TDD approach, this will give you enough ammunition.
Next up is the hands-on project session. Xu Hao will use several technical frameworks as examples (IoC containers, RESTful frameworks, DB Mapper frameworks, etc.) to show how to implement them from scratch in a TDD way, and the details of TDD in practice will be clearly seen.
Not only can you be taught how to use it, but it can also be taught how to persuade others to use it together. For specific chapters, you can take a look at the table of contents
I once heard a very classic saying: if you pay attention to quality, then in the long run, the quality will improve, the cost will decrease; if you pay attention to the cost, then in the long run, the cost will increase, the quality will decrease.
The same applies to test-driven development, where the pursuit of high-quality code and high-quality software systems will drive us to become more and more reliable and competitive developers.
It's time to see the real agile development, and now join the learning, in addition to a hardcore course, but also with the benefits of a high-quality learning community and Xu Hao personally commenting on the code, which is a good opportunity.
Test-driven development
The cattle people want to show you insight