Click to follow asynchronous books , stick to the public number
Share IT good books, technical dry goods and workplace knowledge with you every day
Participate in the topic discussion at the end of the article, and give asynchronous books every day.
- Asynchronous editor
A year ago, it was also the Dragon Boat Festival. By coincidence, one of the translators of this book wrote a preface to another translator's new book, "The Way to Improve the Value of Software Testing." A year later, on the Dragon Boat Festival, the two translators wrote the preface for the translation of "Program Developers' Test Guide: Building High-Quality Software" (hereinafter referred to as "Program Developers' Test Guide") for different styles of software testing. Full of poetry, enjoy the joy of success, and solemnly recommend this book to all software developers and testers.
Looking back, Mr. Zhu Shaomin took over the translation task of this book from the People's Posts and Telecommunications Publishing House, and invited three friends from the testing industry, Yang Xiaohui, Ouyang Chen and Zeng Tianle, to form a translation team and started the translation journey of this book . Although they are test veterans, after taking over the task, they still feel a lot of pressure, and they always do this work with a humble heart. On the one hand, it is the world's first professional book named "Developer Testing", and I hope the Chinese translation will be loved by everyone for a long time. On the other hand, translation is not an easy task, it is more difficult than writing a book. When writing a book, you can write according to your own thoughts and wishes, while the translation is "dancing with anklets". It is often necessary to carefully try to figure out the original author's writing ideas or the specific meaning expressed. Take a glossary we have compiled as an example, in which 218 terms have been collected. After several revisions, several versions have been published. Most terms are easy to unify, and some terms (such as quirk, circular argument, code bloat, etc.) will be controversial, and it is not easy to reach an agreement. After checking various materials, an agreement is finally reached. Even in the face of individual terms (such as Mockist, Test Double, Stub), we feel that most developers are more likely to understand English terms, and there is no need to translate them into Chinese, but for the sake of book specification, try to translate various terms into Chinese, only in the first When it appears once, indicate the original English term.
Ten years ago or earlier, many excellent software companies had independent testing teams, which emphasized the independence and objectivity of testing, and the quality of development largely depended on the quality of independent testing. At that time, Microsoft had about 10,000 professional testers (Software Development Engineer for Test, SDET), which made it one of the few test teams in the world. Therefore, Microsoft was the benchmark for many companies in that era. Everyone learns how Microsoft Take quizzes and attend training sessions run by Microsoft veterans. At that time, in the projects we had personally experienced, developers did very little testing, and more testing was done by professional testing teams. Even if everyone thinks that "unit testing should be done by developers", the coverage rate of unit testing is very low, its effect is still not ideal, and there are very few remarkable projects. Many projects have implemented developer testing, but few have succeeded. Even some projects want to get rid of independent testing teams and go online directly, but the results are also unsuccessful.
However, in the last few years agile development has taken off and it has blossomed everywhere, and all developers have become more and more concerned about quality and are starting to do more and more testing. The Microsoft Test Corps began to disintegrate in 2010 and disappeared in 2014. The vast majority of SDETs quickly integrated into the development team and became a member of development engineers, while the remaining SDETs either changed their careers and went to work such as operation and maintenance, technical support, etc. Either quit and go to another company to continue full-time testing work. Today, companies such as Google, Facebook, etc. have become new benchmarks, and people are beginning to admire a very simple engineer culture and a fusion of development and testing. In such an environment, developers not only need to complete the code, but also need to make every effort to ensure the quality of the code, requiring developers to do enough testing. However, developers are not born to do testing, and their testing ability is relatively weak. Even some developers still reject testing in today's agile development environment. Developer testing is not optimistic in China. There are objective factors and subjective factors. factor, but needs to change anyway.
If testing is done according to the waterfall model in the past, with development first and testing later, developers will encounter psychological and mental obstacles. In theory, Test Driven Development (TDD) solves this problem completely, because testing comes first and development comes after. Before development, the thinking of the test will not be affected by the thinking of the implementation; the implemented code has not yet, and naturally there is no psychological obstacle. The ideal is very rich, and the reality is very skinny. The application of TDD is still rare, because the specific implementation of TDD will face various difficulties, such as bringing extra workload to developers, how to get rid of the habit of writing code in the past, etc. For example, when implementing TDD, we often hear developers say, "Give me double the time". Due to the increased workload, it is difficult to implement TDD under schedule pressure, or in other words, many teams do not know how to implement TDD, how to complete software development more efficiently and improve quality, not only to satisfy customers, but also to bring productivity . If the management has firm determination and dares to make corresponding changes in organization, process and strategy, TDD can bring the double benefits of "quality" and "productivity". the cost of.
Developer testing is not limited to TDD, unit testing and integration testing. Interaction testing between components and higher-level testing by calling the system will also appear in developer testing. Developer testing does not only use testing techniques. Testability, dependencies, reuse and contract programming, defensive programming and other techniques aimed at building high-quality code are also closely related to developer testing. Testing can't really guarantee quality, and software quality is slowly formed in the process of design and programming. From this point of view, developer testing is more important. When starting to construct a function, they must think about how to test it. Rather than finding code errors, they are more concerned with how to avoid errors. In successful teams, every member of the team shares the philosophy of building high-quality software (the subtitle of this book). They collaborate with clients, delivery teams, trying to understand what helps clients succeed and how to find the most efficient and easiest solutions. This book is discussed from this perspective to help developers properly understand and master developer testing, and solve the problems that developers encounter in testing from quasi-unit testing to test doubles, mocking frameworks, different TDD patterns, etc. various obstacles. There are other features of this book, let us introduce them one by one.
First, it's not "developer tests written by test experts", it's "developer tests written by development experts". The book does not spend too much space on the concept of testing, test design techniques, and unit testing tools (which may be the focus of our previous implementation of developer testing), but focuses on testability and the coding style that affects testing. , the way to implement developer testing, the construction of test environment and conditions, the location and role of developer testing in all testing activities, etc. (these are the issues that really affect developer testing efficiency). Therefore, this book has good practical value for developers.
Secondly, this book is not a "mountain", but a number of "sweet spots". Except for the first three chapters that introduce the basic concepts and terminology of testing, the other chapters are relatively independent. problems, solutions, precautions, etc. Even if we read another chapter after a long time, or skip individual chapters that are not of interest, it does not affect our reading experience or gain at all. "Dessert" is also hidden in each chapter - each chapter is interspersed with some "tips", "experiences" or "precautions", etc., to enlighten readers, and readers to be inspired or alerted.
Furthermore, this book is rich in examples, step by step. For example, Section 14.1 uses 8 examples of "a simple search engine" to introduce step by step how the classic style of TDD is implemented. The content of this book is well arranged, there are primary and secondary, and the primary and secondary are clearly defined. For example, many testing books have a detailed introduction to the "Requirements-based Testing Method", but this book is quickly covered with less space. As for the key content, such as testability, Mock technology and TDD, two chapters are used to describe their different aspects. In Mock technology, it introduces how to apply different Mock objects—stub objects, pseudo objects, mock objects, listeners, and dumb objects one by one, and reflects their professional standards.
Finally, developer testing in this book is not "in isolation" but "in context" (context is one of the most important concepts in software engineering). The book puts developers and testers in a scenario, allowing readers to better understand the cause and effect of a problem. Put the problem in the code (many are the code from the actual product), which is convenient for readers to map to their own products and code, and imagine whether the solution to the problem is suitable for them, leaving the reader with a larger space for thinking. Putting testing activities in actual R&D projects, the difference between unit testing and module integration and independent module testing is not so obvious. The book does not avoid these practical problems, but helps readers see the real process of these tests, so that readers can Strategic choices can be made on a project-by-project basis.
We are very happy to participate in the translation of this book. Although the translation process is very hard, it is also a happy learning process, which can solve some of our doubts about developer testing. The only regret is that we met each other late at night! If you read this book a few years ago, in your previous work, many things will be done in a better way, such as TDD, unit testing, such as code quality inspection, agile integration team... I believe this book will be helpful to developers. With greater help, the developer's testing ability will be gradually improved. Developers have done a good job of testing, and they will feel very relaxed and more confident when delivering project code in the future.
The Developer's Guide to Testing: Building High-Quality Software
The Developer's Guide to Testing: Building High-Quality Software
[Sweden] by Alexander Tallinde
Click on the cover to buy the paper book
The first test book for developers to write testable code, avoid defects, and improve software quality, translated and recommended by test experts Zhu Shaomin, Yang Xiaohui, Ouyang Chen, and Zeng Letian.
In this book, Alexander first shows those tests that need attention. He introduces some overlooked but useful concepts, such as Programming By Contract. He taught us how to design code that can be easily tested. He highlights two goals that I like:
Build highly readable, specification-based tests while maintaining the value of documentation;
Destroy one of the biggest enemies of high-quality systems - all kinds of bad-smelling replication.
He takes a practical, balanced approach to doing TDD well, and presents traditional TDD and Mockist TDD application techniques to give us a comprehensive introduction to unit testing .
This book explains the testing techniques developers need to know in order to help them build high-quality software. It explains how to write test code, how to perform unit tests, and how to refactor test-driven development. Key test concepts to help readers absorb quickly, as well as techniques and must-know methods that need to be mastered when writing test cases. Also includes testbenches or tools that need to be learned. The authors of this book also answer many questions that development teams often encounter in testing, including: What is code testing? What makes it difficult to test? When enough tests are done etc.
Interact today
Do you think developers need testing skills? Why? The deadline is 17:00 on May 11th, leave a message + forward this event to the circle of friends, the editor will draw 3 readers to give away 1 paper book and 2 e-reading version 100 yuan asynchronous community vouchers , (the message has the most likes automatically get one). Asynchronous book background reply "May new book" to enter the new book exchange group, get first-hand new book information, click here to go directly to the event .
Recommended reading
New Book List for May 2018 (Welfare at the end of the article)
The most complete Python book list of asynchronous books
A must-have algorithm book list for programmers
The first Python neural network programming book
Long press the QR code to follow us
Share IT good articles with you every day.
Reply " Follow " in the background of " Asynchronous Books " , you can get 2000 online video courses for free ; recommend friends to follow the prompts to get the book gift link, and get a free asynchronous e-reading book . Come join now!
Click to read the original text and buy the "Program Developer's Test Guide to Build High-Quality Software"