Kent Beck - Extreme Programming. Test Driven Development

Genre: ,

Series:
Age restrictions: +
Language:
Original language:
Translator (s):
Publisher:
Publishing city: St. Petersburg
The year of publishing:
ISBN: 978-5-496-02570-6 The size: 382 Kb

The presented fragment of the work was posted by agreement with the distributor of legal content LLC "Liters" (no more than 20% of the original text). If you believe that the posting of the material violates someone's rights, then.

Readers!

Have you paid, but do not know what to do next?

Attention! You are downloading an excerpt permitted by law and the copyright holder (no more than 20% of the text).
After reviewing, you will be prompted to go to the copyright holder's website and purchase the full version of the work.

Book Description

The return of the famous bestseller. Elegant, flexible and understandable code that is easy to modify, which works correctly and which does not throw unpleasant surprises for its creators. Is this really possible? To achieve your goal, try testing your program before you write it. It is this paradoxical idea that underlies the TDD (Test-Driven-Development) methodology. Nonsense? Do not rush to draw hasty conclusions. Considering the use of TDD on the example of developing real program code, the author demonstrates the simplicity and power of this technique. The book contains two software projects, fully and fully implemented using TDD. The examples are followed by an extensive catalog of TDD-style techniques and TDD-related patterns and refactorings. The book will be useful for any programmer who wants to increase the productivity of his work and enjoy programming.

Last impression of the book

SharerSharpened:
16-12-2018, 02:17

Before reading this book, I tried to write tests for the articles I read, but only with it did I start to get good at it.

I read it twice. The first time I just read it.

Understood nothing. The second time I wrote the code while reading the book, and then finally it dawned on me what was what and most importantly - I felt my step size by which I can change the code without losing control over it. I was pleased with the second chapter where, together with the author, he wrote his unit testing system in Python, the feeling was as if you were doing an operation on your own brain (in fact, this is exactly the comparison that the author himself made) - one careless movement and nothing works, you need to move in very small steps. I read the third chapter selectively, maybe someday I will.

Collapse

⬇ Other comments

This book is about extreme programming. Extreme programming, often referred to as "XP", is a simplified production methodology for small to medium-sized development teams. software product in the face of unclear or rapidly changing requirements. This book is intended to help you determine if XP is appropriate for your situation ...

About the XP series

Extreme Programming, often referred to as XP, is a development discipline software and doing business in the field of creating software products, which focuses the efforts of both parties (programmers and businessmen) on common, quite achievable goals. XP teams are producing quality software at great speed. The techniques that are part of the XP discipline described in this book were chosen because they are based on human creativity and the acceptance that a person is an unstable and error-prone creature.

XP is often presented as a collection of techniques, but XP itself is not a finish line. You don't need to practice and develop XP better and better in order to get the long-awaited gold star at the end of this process. On the contrary, XP is the starting line. XP asks the question, "How minimal can our efforts be so that we can continue to produce quality software?"

The beginning of the answer to the question sounds like this: if we want to develop quality programs without clutter and confusion, we must be ready to fully and completely implement several techniques in our team, which we are going to use to the fullest. If we use these techniques in half, the problems remain, and in order to solve them, it will be necessary to move to using the techniques to the fullest. If we restrict ourselves to half measures, over time we will get so confused in them that we will not be able to understand that the main things that are created by the labor of programmers are born thanks to programming.

I said "start the answer to" because the continuation doesn't really exist. The people who created and implemented XP also thought about solving this issue. Having tried to use XP, they stepped over the threshold and went into the unknown. When they returned, they told their story. Their thoughts are signs placed along the road: “Dragons live here”, “After 15 km good view"," This area is dangerous in the rain. "

I'm sorry, but it's time for me to go program.

Foreword

Extreme programming (

eXtreme Programming

XP) defines coding as a key and fundamental activity when working on a software project. It might be wrong!

I think it is worth remembering my own experience in software development. I work in an environment where the product being developed is constantly in working condition, and at the same time, changes are constantly being made to it. The timeline for the release of the next workable version is monstrously tight, and at the same time, a huge technical risk hangs over all this. In such an environment, the ability to fix one's fellow-in-arms is an art without which one cannot survive. The exchange of information both within a team and between several teams, which are often geographically separated, is done using code. We read the code in order to understand the structure of new or modified program interfaces of the system. Life cycle and behavior complex objects are defined using test cases, that is, again using code. Problem reports are accompanied by test cases demonstrating the problem, again using code for this. Finally, we are constantly busy improving the existing code, making it more productive, more flexible, and more understandable. Obviously, in such conditions, software development is almost entirely based on coding, but at the same time we manage to successfully complete projects on time, thus, this approach quite viable.

Don't assume that all you need to successfully implement a software project is reckless brutal programming. Developing software is very difficult, and developing high-quality software and getting the job done on time is even more difficult. For the approach I have described to work, you need to consistently apply important additional rules and techniques. This is where Kent Beck begins his thought-provoking book on XP.

I partnered with Kent and used the XP episodes on a small but infamous project called JUnit.

Introduction

This book is about extreme programming (

eXtreme Programming

XP). Extreme Programming is a simplified production methodology for small and medium-sized teams of professionals involved in software development in an environment of unclear or rapidly changing requirements. This book is intended to help you determine if XP is appropriate for your situation.

For many, XP looks like a set of methods of work organization that are quite acceptable and justified from the point of view of common sense. Then why is XP programming called extreme? The point is that XP takes many of the accepted and widely used programming principles to extreme levels.

If revision of the code is good, then we will revise the code constantly (programming in pairs);

If testing is good, each project participant will constantly test the program code (unit testing), even customers ( functional testing);

If design is good, then design should be made an integral part of the daily work of each of the project participants (code revision);

Extreme programming

Dedicated to my father and also thanks to Cindee Andres, my wife and partner, for demanding that I ignore her and write. Thanks to Bethany, Lincoln, Forrest and for not distracting me and letting me write.

About the XP series

Extreme Programming, often referred to as XP, is a software engineering and software business discipline that focuses the efforts of both programmers and business people on common, achievable goals. XP teams are producing quality software at great speed. The techniques that are part of the XP discipline described in this book were chosen because they are based on human creativity and the acceptance that a person is an unstable and error-prone creature.

I said "start the answer to" because the continuation doesn't really exist. The people who created and implemented XP also thought about solving this issue. Having tried to use XP, they stepped over the threshold and went into the unknown. When they returned, they told their story. Their thoughts are signs placed along the road: "Dragons live here", "After 15 km, a good view opens up", "This area is dangerous in the rain."

I'm sorry, but it's time for me to go program.

Kent Beck, Series Consultant

Foreword

Extreme programming ( eXtreme Programming, XP) defines coding as a key and fundamental activity when working on a software project. It might be wrong!

I think it is worth remembering my own experience in software development. I work in an environment where the product being developed is constantly in a healthy state, and at the same time, changes are constantly being made to it. The timeline for the release of the next workable version is monstrously tight, and at the same time, a huge technical risk hangs over all this. In such an environment, the ability to fix one's fellow-in-arms is an art without which one cannot survive. The exchange of information both within a team and between several teams, which are often geographically separated, is done using code. We read the code in order to understand the structure of new or modified system programming interfaces. The life cycle and behavior of complex objects are defined using test cases, that is, again using code. Problem reports are accompanied by test cases demonstrating the problem, again using code for this. Finally, we are constantly busy improving the existing code, making it more efficient, more flexible, and more understandable. Obviously, in such conditions, software development is almost entirely based on coding, but at the same time we manage to successfully complete projects on time, so this approach is quite viable.

Kent was among those Tektronix executives who recognized the enormous potential of coupled-pair programming for developing complex engineering applications in Smalltalk. Together with Bard Cunningham (Ward Cunningham), Kent became the inspiration for the development of programming techniques from patterns (it is also called programming using patterns - patterns programming which has greatly influenced my own career. XP describes an approach to software development that combines the techniques used by numerous successful developers who have studied a lot of literature on organizing the work of programmers and tried out many methods and procedures for developing a software product. Like programming by example, XP provides a set of best practices, such as unit testing, programming in pairs, and rewriting code. In XP, these techniques are combined in such a way as to complement and often control each other. The main purpose of this book is to talk about the interaction and joint use of various techniques. All programming techniques have one goal - to create a software product with a given functionality by a given deadline. OTI's highly successful Just In Time Software process is not XP in pure form however, there is a lot in common between the two approaches.

I collaborated with Kent and used the XP episodes on a small but infamous project called JUnit. His views and approaches to software development have always made me think about how I personally got used to working on a software project. Without a doubt, XP challenges many of the traditional approaches used in the programming industry. After reading this book, you can decide for yourself whether you need to use XP in your work or not.

Extreme programming

About the XP series

I said "start the answer to" because the continuation doesn't really exist. The people who created and implemented XP also thought about solving this issue. Having tried to use XP, they stepped over the threshold and went into the unknown. When they returned, they told their story. Their thoughts are signs placed along the road: "Dragons live here", "After 15 km, a good view opens up", "This area is dangerous in the rain."

I'm sorry, but it's time for me to go program.

Kent Beck, Series Consultant

Foreword

Extreme programming ( eXtreme Programming, XP) defines coding as a key and fundamental activity when working on a software project. It might be wrong!

Kent was among those Tektronix executives who recognized the enormous potential of coupled-pair programming for developing complex engineering applications in Smalltalk. Together with Bard Cunningham (Ward Cunningham), Kent became the inspiration for the development of programming techniques from patterns (it is also called programming using patterns - patterns programming which has greatly influenced my own career. XP describes an approach to software development that combines the techniques used by numerous successful developers who have studied a lot of literature on organizing the work of programmers and tried out many methods and procedures for developing a software product. Like programming by example, XP provides a set of best practices, such as unit testing, programming in pairs, and rewriting code. In XP, these techniques are combined in such a way as to complement and often control each other. The main purpose of this book is to talk about the interaction and joint use of various techniques. All programming techniques have one goal - to create a software product with a given functionality by a given deadline. OTI's highly successful Just In Time Software process is not pure XP, but there are many similarities between the two approaches.

I partnered with Kent and used the XP episodes on a small but infamous project called JUnit. His views and approaches to software development have always made me think about how I personally got used to working on a software project. Without a doubt, XP challenges many of the traditional approaches used in the programming industry. After reading this book, you can decide for yourself whether you need to use XP in your work or not.

Erich Gamma

Introduction

This book is about extreme programming ( eXtreme Programming, XP). Extreme Programming is a simplified production methodology for small and medium-sized teams of professionals involved in software development in an environment of unclear or rapidly changing requirements. This book is intended to help you determine if XP is appropriate for your situation.

If revision of the code is good, then we will revise the code constantly (programming in pairs);

If testing is good, each project participant will constantly test the program code (unit testing), even customers (functional testing);

If design is good, then design should be made an integral part of the daily work of each of the project participants (code revision);

If simplicity is good, then we should keep the system as simple as possible to provide the current required level of functionality (the simplest thing that is likely to work); if architecture is important, then each of the project participants will constantly work on defining and revising architecture (metaphor);

If integration testing is important, then it is necessary to collect and test the developed system several times a day (ongoing integration);

If small iterations are good, you need to make the iterations very, very small - seconds, minutes, maybe hours, but not weeks and months, and by no means years (planning game).

When I first decided to articulate the essence of XP for myself, I imagined a set of handles on the control panel. Each handle corresponded to a certain method, about which from its personal experience I knew it was quite effective. Each handle allowed one or another technique to be used to a certain extent, from 1 to 10. I tried setting all the arms to their maximum position (10) and was surprised to find that the full range of techniques I was considering remained stable, predictable, and flexible.

XP generates two sets of promises:

XP promises programmers that each of them will work on solving really important problems every working day. Each of them will never find themselves stranded alone. Each of them will be able to do everything in their power to make the developed system successful. Each of them will be able to make a decision in exactly the area in which he is competent, and if in some area he is not competent enough, he will not participate in the decision making.

XP promises customers and managers that they will get the most out of every week of project development. Every few weeks, they will be able to see progress towards their goals. They will be able to change the direction of the project in the middle of development, without fear of additional extraordinary costs.

In short, XP promises to reduce project risk, improve responsiveness to business change, improve project productivity, and make software development more enjoyable - all at the same time. I'm not kidding, stop laughing. Just read this book and you can check for yourself if I'm crazy.

This book

This book talks about things related to the XP method - its roots, philosophy, all sorts of stories and myths. The book is intended to help you make an informed decision about whether to use XP in your own project. If, after reading this book, you decide not to use XP when working on your project, I will consider the main goal achieved in the same way as if, after reading this book, you would have decided that XP is what you need. necessary. The second purpose of this book is to help those of you who are already using XP. After reading the book, such readers will be able to better understand this technique.

This book does not contain precise instructions on how exactly the extreme programming process should be carried out. You won't see many examples, algorithms, or programming stories in it. To get all this, you can search the Internet, talk to some of the project contributors, wait for books on this to appear, or start creating such material yourself.

The further fate of the discipline of XP software development that I described is in the hands of a group of people (you may be one of them) who are dissatisfied with what exists on this moment traditional methods of organizing the work of programmers. Do you need the best way software development, you want to build more productive and welcoming relationships with your customers, you want to make the programmers working under your direction happier, more loyal and more productive. In short, you want a significant advantage and you are not afraid to take advantage of new ideas in order to gain that advantage. However, before you take risks, you want to make sure that you are at least not a complete fool.

XP tells you to do your job in a very different way than you are used to. In some cases, XP's recommendations are completely contrary to generally accepted norms. On the this moment I believe that XP can only be used by those who have good reason to change the existing order of things. However, if such reasons exist, you can start using XP right now. I wrote this book so that you can learn more about these reasons.

What is XP?

What is XP? XP is a simplified, efficient, flexible, predictable, scientifically sound and highly enjoyable way to develop software that includes low level risk. XP differs from other techniques in the following ways.

By using extremely short development cycles, XP offers fast, real and permanent feedback.

XP uses incremental planning, resulting in an overall project plan emerging rather quickly, but this implies that this plan evolves throughout the life of the project.

XP uses a flexible timeline for delivering functionality to improve responsiveness to changing businesses and changing customer requirements.

XP is based on automated tests developed by both programmers and customers. Thanks to these tests, it is possible to monitor the development process, ensure the correct evolution of the system and immediately detect existing defects in the system.

XP is based on oral communication, tests and source code. These three tools are used to exchange information about the structure of the system and its behavior.

XP is based on an evolving design process that lasts as long as the system itself.

XP is based on the close interaction of programmers with the most common skills and capabilities.

XP is based on techniques that satisfy both the short-term instincts of individual programmers and the long-term interests of the project as a whole.

XP is a software engineering discipline. This is a discipline because there are certain things within XP that you must do if you intend to use XP. You don't have to choose whether or not to write tests, because if you don't, the programming you are doing is not extreme: end of discussion.

The XP methodology is designed to work on projects that can be worked on by two to ten programmers, who are not constrained by the rigid framework of the existing computer environment and in which all the necessary work related to testing can be completed within one day.

XP scares or annoys some people who are using this technique for the first time. However, no idea behind XP is new. In a sense, the XP methodology is conservative - all the techniques used within its framework have been tested for decades (as for the implementation strategy) and even centuries (as for the management strategy) of practice.

New to XP are the following features:

All these well-known techniques are gathered under one roof;

The intensity with which these techniques are being introduced into daily work has been pushed to the extreme;

The techniques used support each other to the greatest extent possible.

Adequacy

In his works The Forest People and The Mountain anthropologist Colin Turnbull describes two very different societies. In the mountains, the resources necessary for life are not enough, and people are always on the verge of hunger. The culture that has emerged under these conditions looks terrifying. Mothers abandon their children in order to survive on their own. Food can be fatal. Cruelty, brutality and betrayal are common and everyday.

Unlike mountains, forests are rich in resources. To provide himself with food for the whole day, a person only needs to spend about half an hour. Forest culture is the opposite of mountain culture. Adults take part in raising and raising common children, who grow up in love and care until they are capable enough to take care of themselves on their own. If one person by mistake kills another (deliberate murder is not familiar to these people), he is expelled from society. However, in this case, the exile simply has to retire to the forest and spend several months there, and even then some members of the tribe bring him food and gifts.

XP is an attempt to answer the question: How would you personally program if you had enough time? Actually, you don't have any extra time, because programming is a business after all. In any business, the winner is the one who gets the job done faster. However, if you had the time, you would probably pay attention to test design; you would most likely re-architect the system if you came to the conclusion that it was necessary; you would probably communicate more with your fellow programmers, as well as with the customer.

This feeling of sufficiency looks more humane, in contrast to situations where programmers are struggling to stay within the given time frame, are out of schedule, do not have time to complete a large amount of extremely important work just in order to have time to deliver a project on time. Haste prevents programmers from fully demonstrating their talent and enjoying their work. However, when you start learning XP, you must understand that feeling of sufficiency is also good business. A sense of sufficiency becomes a source of efficiency in the same way that a sense of lack gives rise to failures in work, leads to the appearance of defects and a decrease in quality, and, ultimately, to a decrease in labor productivity.

Book plan

The book is written as if you and I are together creating a new discipline of software development. We start by exploring our basic understanding of software development. After that, we actually create a new discipline. Then we explore the implications of what we have created - how it can be implemented and used in practice, when it should not be used, and what opportunities it opens up for the business.

The book is divided into three parts.

Problem: in chapters starting with Risk: the main problem and ending Back to basics, the problem that extreme programming is trying to solve is determined, and criteria are established by which the quality of the solution can be assessed. In this part, you will get an overview of the extreme programming technique.

Solution: in chapters starting with Short review and ending Testing strategy, the abstract ideas presented in the first part of the book turn into a set of methodologies for a specific discipline. This chapter does not contain any information on how exactly you can apply the described techniques in practice. Instead, it is about the general form of each of the techniques. As I discuss each technique, I relate it to the problems and principles discussed in the first part of the book.

XP implementation: in chapters starting with XP implementation and ending XP in action, discusses many issues related to the implementation of XP - how to implement XP, what to expect from the different people involved in an XP project, what kind of XP people have in the business world.

Acknowledgments

I am speaking to readers in the first person not because the book presents my own ideas, but because I am telling you about my own perception of these ideas. Most of the techniques used in XP are as old as all programming.

Ward Cunningham is my primary source of material for the book. Anyway, I've spent the last fifteen years just trying to explain to other people what Ward has been doing in practice for a long time. Thanks also to Ron Jeffries for trying this too and then making a big improvement. Thanks to Martin Fowler for explaining all this in simple, soft language and without nervous breakdowns. Thanks to Erich Gamma for the lengthy conversations combined with the contemplation of swans in Limm, and also for the fact that he did not let me leave him with bad thoughts in my head. And of course, none of this would have happened in my life if I didn't have a role model like my father, Doug Beck, who has honed his programming skills over the years.

Thanks to the C3 team at Chrysler for accompanying me on my research. And also a special thank you to our managers Sue Unger and Ron Savage for having the courage to give us a try.

Thanks to Daedalos Consulting for helping me write this book.

The Watching Champion goes to Paul Chisholm for his abundant, succinct, scrupulous, and often downright annoying comments. Without his help this book would not be half as popular.

I really enjoyed communicating with all those who carried out preview of what I wrote.

Their work was of great help to me. I cannot find words of gratitude for the fact that they had the patience to read to the end all this prose, for many of them set out in a foreign language.

Thanks to (randomly listed in which I received comments from them) Greg Hutchinson, Massimo Arnoldi, Dave Cleal, Sames Schuster, Don Wells, Joshua Kerievsky, Thorsten Dittmar, Moritz Becker, Daniel Gubler, Christoph Henrici, Thomas Zang, Dirk Koenig, Dierk Koenig Miroslav Novak, Rodney Rayan, Frank Westphal, Paul Trunz, Steve Hayes, Kevin Bradtke, Jeanine De Guzman, Tom Kubit, Falk Bruegmann, Hasko Heinecke, Peter Merel, Rob Mee, Pete McBreen, Thomas Ernst, Guido Guido Haechler, Dieter Holz, Martin Knecht, Dirk Crump ( Dierk Krampe, Patrick Lisser, Elisabeth Maier, Thomas Mancini, Alexio Moreno, Rolf Pfenninger and Matthias Ressel.

From the publisher

Send your comments, suggestions, questions to the address Email [email protected](publishing house Peter, computer edition).

We'd love to hear from you!

All source texts given in the book can be found at http://www.piter.com/download.

On the publisher's website http://www.piter.com you will find detailed information about our books.

Problem

This part of the book prepares the scene on which extreme programming should appear in the future. It describes various aspects of the problem to be solved by forming a new discipline of software development.

This part discusses the basic assumptions we need to keep in mind when choosing our software development methodology - the driving metaphor, the four meanings, the principles formed from those meanings, and the activities that need to be structured within the new discipline of software development.

Risk: the main problem

The existing disciplines of software development do not work and do not give the desired economic effect. This problem has enormous economic and humanitarian significance. We need a new way of software development.

The main problem in software development is risk.

Here are some examples of risk.

Offset graphs- the day of delivery of the work comes, and you are forced to inform the customer that the system being developed will not be ready for another six months.

Closing a project- after several shifts of the schedule and postponements of the date of delivery, the project is closed, even without being brought to the stage of testing in working conditions.

The system loses its usefulness- the developed software is successfully installed in a real production working environment, but after a couple of years of use, the cost of making changes to it and / or the number of defects increases so much that it becomes cheaper to replace the system with a new development.

- the software system is installed in a real production working environment, but the number of defects and deficiencies is so great that the system is not used.

- the software system is installed in a real production environment, but it turns out that it does not actually solve the business problem it was originally intended to solve.

Changing the nature of business- the software system is being installed in a real production environment, but over the past six months, the problem that the system was intended to solve has lost its relevance, and instead, the business is faced with a new, even more serious problem.

Lack of opportunities- the software system has a lot of potentially interesting features, each of which was very pleasant to program, but it turns out that none of these features does not bring much benefit to the customer.

Staff turnover- within two years of work, all good programmers who worked on the project, one by one, hated the developed software system and left for another job.

On the pages of this book, you will read about extreme programming ( eXtreme Programming, XP) is a software development discipline that focuses on risk reduction at all levels of the development process. XP contributes to a significant increase in productivity and improvement of the quality of the developed programs, in addition, it is a very entertaining practice that gives all its participants a lot of pleasure.

How does XP mitigate the above risks?

Offset graph- XP proposes to use very short release times for each next version. It is assumed that each next ready-to-use version of the system is developed within a maximum of several months. Thus, the amount of work within each version is limited, which means that if there is a shift, it is less significant. Each version will include multiple iterations of the customer requested features, each of which takes one to four weeks to develop. This provides flexible and responsive feedback to the customer, so that he gets an idea of the current progress of work. Within each iteration, planning in accordance with XP is carried out in terms of several tasks that must be solved to obtain the next iteration. One to three days are allotted for the solution of each of the tasks. As a result, the team can detect and fix problems even during iteration. Finally, XP assumes that the highest priority features will be implemented first. Thus, any features that could not be implemented within the framework of this next version of the software product have a lower priority.

Closing a project- within XP, the customer must determine the smallest allowable set of capabilities that the minimum workable version of the program should have that makes sense from the point of view of solving business problems. Thus, programmers will need to make a minimum amount of effort in order for the customer to understand whether he needs this project or not.

The system loses its usefulness- within XP, a huge number of tests are created and maintained, which are launched and restarted after any change is made to the system (several times a day), thanks to this it is possible to carefully monitor the quality of the program being developed. XP keeps the system in excellent condition at all times. Defects are simply not allowed to accumulate.

Number of defects and deficiencies- within XP, the system being developed is tested both by programmers who create tests for each separate developed function, and by customers who create tests for each individual implemented system feature.

Inconsistency with the problem being solved- within XP, the customer is an integral part of the team that works on the project. The specification of the project is constantly revised throughout the entire period of work on the project, thanks to which any clarifications and discoveries that the customer informs the development team about are immediately reflected in the developed program.

Extreme Programming: Test Driven Development

Dedicated to Cindy: the wings of my soul

Publishing rights obtained by agreement with Addison-Wesley Longman. All rights reserved. No part of this book may be reproduced in any form whatsoever without the written permission of the copyright holders.

The information contained in this book has been obtained from sources considered reliable by the publisher. However, in view of possible human or technical errors, the publisher cannot guarantee the absolute accuracy and completeness of the information provided and is not responsible for possible errors associated with the use of the book.

ISBN 978-0321146533 English.

ISBN 978-5-496-02570-6

Foreword

Clean code that works(clean code that works), in this short but pithy phrase, coined by Ron Jeffries, is the whole point of Test-Driven Development (TDD). Clean code that works is a goal worth striving for because

This is a predictable way of developing programs. You know when the work can be considered finished and not worry about a long series of mistakes;

Gives you a chance to learn the lessons the code teaches. If you use the first idea that comes to mind, you will not have a chance to implement the second, better idea;

Improves the life of the users of your programs;

Allows your colleagues to count on you and you to count on them;

It's more enjoyable to write code like this.

But how do you get clean code that works? Many forces prevent us from getting clean code, and sometimes we can't even get code that just works. To get rid of a lot of problems, we will develop the code relying on automated testing. This style of programming is called test-driven development. According to this technique

New code is written only after the automated test is written and fails;

Any duplication is eliminated.

Two simple rules, is not it? However, they generate complex individual and group behavior with many technical implications:

During the design process, we constantly run the code and get an idea of its work, this helps to make the right decisions;

We write tests ourselves, because we can't wait for someone else to write tests for us;

Our development environment must respond quickly to small code modifications;

The design of the program should be based on the use of many self-contained, loosely coupled components to make it easier to test the code.

The two TDD rules mentioned dictate the order of the programming steps.

1. Red - write a small test that doesn't work, and may not even compile.

2. Green - make the test run as fast as possible, without thinking about correct design and clean code. Write just enough code to make the test work.

3. Refactoring - eliminate any duplication from the written code.

Red - green - refactoring is the mantra of TDD.

If we assume that this style of programming is possible, we can assume that thanks to its use, the code will contain significantly fewer defects, in addition, the purpose of the work will be clear to everyone who takes part in it. If so, then developing only the code needed to pass the tests also has social implications:

With a sufficiently low density of defects, the Quality Assurance (QA) team will be able to move from responding to errors to preventing them;

By reducing the number of unpleasant surprises, project managers will be able to more accurately estimate labor costs and involve customers in the development process;

If the topics of technical discussions are clearly defined, programmers can interact with each other on a regular basis, rather than once a day or once a week;

Again, with a sufficiently low defect density, we will be able to have an integrated work product every day with new functionality added to it, so that we can enter into a completely new type of business relationship with our customers.

So the idea is simple, but what is our interest? Why should a programmer take on the extra responsibility of writing automated tests? Why would a programmer take tiny little steps forward when his brain is able to think through a much more complex design structure? Bravery.

Bravery

TDD is a way to manage fear in the programming process. I don't mean fear of falling from a chair or fear of a boss. I mean the fear of a problem "so difficult that I have no idea how to solve it yet." Pain is when nature tells us: "Stop!" And fear is when nature tells us: "Be careful!" Being cautious isn't a bad thing, but besides being beneficial, fear has some negative effects on us:

Fear forces us to think in advance and carefully what this or that action can lead to;

Fear makes us communicate less;

Fear makes us intimidated by reviews of our work;

Fear makes us irritable.

None of this is useful for the programming process, especially if you are working on a complex problem. So, we are faced with the question of how to get out of a difficult situation and

Do not try to predict the future, but immediately begin practical study of the problem;

Not fencing off from the rest of the world, but increasing the level of communication;

Do not avoid responses, but, on the contrary, establish reliable feedback and, with its help, carefully monitor the results of your actions;

(you have to deal with the annoyance yourself).

Compare programming to lifting a bucket from a well. The bucket is filled with water, you rotate the lever, winding the chain around the gate and lifting the bucket up. If the bucket is small, a regular, freely rotating collar is fine. But if the bucket is large and heavy, you will get tired before you pick it up. To be able to rest between turns of the lever, a ratchet is needed to keep the lever in place. The heavier the bucket, the more often the teeth on the ratchet gear should follow.

Tests in TDD are the teeth on the ratchet gear. By making the test work, we know that the test now works, now and forever. We are one step closer to completing the work than we were before the test started working. After that we force the second test to work, then the third, the fourth, and so on. The more complex the problem facing the programmer, the less functionality each test should cover.

Book readers Extreme Programming Explaine must have noticed the difference in tone between Extreme Programming (XP) and Test-Driven Development (TDD). Unlike XP, TDD is not absolute. XP says "you have to master this and that to move on." TDD is a less specific technique. TDD assumes there is an interval between decision making and results, and offers tools to control the length of this interval. “What if, for a week, I design an algorithm on paper and then write the code using a test first approach? Will this be TDD compliant? " Of course it will be. You know the length of the interval between making a decision and evaluating the results and consciously control this interval.

Most people who have mastered TDD claim that their programming practice has changed for the better. Infected by tests(test infected) is the definition Erich Gamma coined to describe this change. Once you've mastered TDD, you find yourself writing significantly more tests than you used to, and moving forward in tiny steps that would have seemed pointless to you before. On the other hand, some programmers, having become familiar with TDD, decide to revert to old practices, reserving TDD for special cases when conventional programming does not lead to the desired progress.

Certainly, there are problems that cannot (at least for the moment) be solved with tests alone. In particular, TDD does not allow to mechanically demonstrate the adequacy of the developed code in terms of data security and reliability of parallel operations. Of course, security is based on code that should be free of defects, but it is also based on human participation in data protection procedures. The subtle problems of concurrency cannot be reproduced with certainty by simply running some code.