The book "Extreme programming: development through testing"

The return of the famous bestseller. Elegant, flexible and clear code that is easy to modify, which works correctly and that does not give unpleasant surprises to its creators. Is this possible? To achieve the goal, try testing the program before it is written. It is this paradoxical idea that underlies the TDD methodology (Test-Driven-Development - testing-based development). Nonsense? Do not rush to make early conclusions. Considering the use of TDD on the example of developing real software code, the author demonstrates the simplicity and power of this technique. The book contains two software projects, fully implemented using TDD. Examination of examples is followed by an extensive catalog of TDD-style techniques, as well as patterns and refactorings related to TDD. The book will be useful for any programmer who wants to improve the performance of their work and get pleasure from programming.

Clean code that works (clean code that works) - in this short, but meaningful phrase, invented by Ron Jeffries, lies the whole point of the development methodology through testing (Test-Driven Development, TDD). Clean code that works is a goal worth striving for because

• It is a predictable way of developing programs. You know when work can be considered complete and not worry about a long series of errors;
• Gives a chance to learn the lessons presented by the code. If you use the very first idea that came to mind, you will not have a chance to realize the second, better idea;
• improves the lives of users of your programs;
• allows your colleagues to rely on you, and you - to rely on them;
• writing such code is more pleasant.

But how to get clean code that works? Many forces prevent us from getting clean code, and sometimes you can’t even get code that just works. To get rid of a lot of problems, we will develop code based on automated testing. This programming style is called development through testing. According to this technique
')
• A new code is written only after an automatic test fails;
• any duplication is eliminated.

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

• in the design process, we constantly run the code and get an idea of ​​its work, it helps to make the right decisions;
• we write the tests ourselves, because we cannot expect someone else to write tests for us;
• our development environment should respond quickly to small code modifications;
• program design should be based on the use of many stand-alone, loosely coupled components in order to simplify code testing.

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

1. Red - write a small test that does not work, and perhaps does not even compile.
2. Green - make the test work as quickly as possible, while not thinking about the correct design and cleanliness of the code. Write just enough code to make the test work.
3. Refactoring - eliminate any duplication from the written code.

Red — green — refactoring is the TDD mantra.

If we assume that such a programming style 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 all who take part in it. If so, then developing only the code necessary for passing the tests also leads to social consequences:

• with a sufficiently low defect density, the quality control team (Quality Assurance, QA) will be able to move from responding to errors to their prevention;
• with a decrease in 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 will be able to interact with each other all the time, rather than once a day or once a week;
• and again, with a sufficiently low defect density, we will be able every day to receive an integrated work product 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 additional responsibility to write automated tests? Why should a programmer move forward with tiny steps when his brain is able to think through a much more complex design structure? Bravery.

Bravery

TDD is a way to control fear in the programming process. I do not mean the fear of falling from a chair or the fear of a boss. I mean the fear of a task “so complicated that I still have no idea how to solve it.” Pain is when nature tells us: “Stop!”, And fear is when nature tells us: “Be careful!” Caution is not bad at all, but besides use, fear has some negative effect on us:

• Fear makes us think ahead of time and carefully what this or that action may lead to;
• fear makes us communicate less;
• Fear makes us scared of reviews about our work;
• fear makes us irritable.

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

• do not try to predict the future, but immediately begin a practical study of the problem;
• do not fence off from the rest of the world, but increase the level of communication;
• not to avoid responses, but, on the contrary, to establish reliable feedback and with its help carefully control the results of their actions;
• (with annoyance, you must do it yourself).

Let's compare the programming with the lifting of the bucket from the well. The bucket is filled with water, you rotate the lever, winding the chain on the gate and lifting the bucket up. If the bucket is small, a normal, freely revolving gate is fine. But if the bucket is large and heavy, you will get tired before you lift it. In order to be able to rest between turns of the lever, a ratchet mechanism is necessary, allowing the lever to be fixed. The heavier the bucket, the more often the teeth on the ratchet gear must 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 were one step closer to completing the work than we were before the test worked. After that, we make the second test work, then the third, fourth, and so on. The more complex the problem facing the programmer, the less functionality each test should cover.

The readers of the book Extreme Programming must have noticed the difference in tone between Extreme Programming (XP) and Test-Driven Development (TDD). Unlike XP, TDD is not absolute. XP says: "To move on, you must master this and that." TDD is a less specific technique. TDD assumes that there is an interval between making a decision and getting results, and offers tools for managing the duration of that interval. “What if during the week I will design the algorithm on paper and then write the code using the“ first tests ”approach? Will it fit TDD? ”Of course it will. You know the magnitude 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. Those infected with tests (test infected) - this definition was invented by Erich Gamma (Erich Gamma) to describe this change. Having mastered TDD, you find that you are writing significantly more tests than before, and move forward with tiny steps that you would have previously thought would be meaningless. On the other hand, some programmers, having become acquainted with TDD, decide to return to the use of previous practices, reserving TDD for special cases when ordinary programming does not lead to the desired progress.

Certainly, there are tasks that are impossible (at least for the moment) to be solved only with the help of tests. In particular, TDD does not allow 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, which should not be defective, but it is also based on human participation in data protection procedures. The subtle problems of parallel execution of operations cannot be reproduced with confidence simply by running some code.

After reading this book, you can:

• start using TDD;
• write automatic tests;
• perform refactoring, implementing solutions one at a time.

The book is divided into three parts.

Part I. On the example of money. An example of developing a typical application code using TDD. This example was borrowed by me from Ward Cunningham many years ago, and since then I have repeatedly used it to demonstrate TDD. It discusses multicurrency arithmetic: performing mathematical operations on monetary values ​​expressed in various currencies. This example will teach you to write tests before the code they are testing and to develop the project organically.

Part II. For example xUnit. An example of testing more complex logic using the mechanism of reflection and exclusion. The example covers the development of an automated testing infrastructure. This example will also introduce you to the xUnit architecture, which is at the core of a variety of testing tools. In the second example, you will learn to move forward with even smaller steps, and also to develop a system using the mechanisms of the system itself.

Part III. Design patterns through testing. Here we look at patterns that will help find answers to many questions, in particular: what tests to write and how to write them using xUnit. In addition, here you will find a description of some selected design patterns and refactoring used to create the examples for this book.

I (Kent Beck) wrote examples as if we were participating in a pair programming session. If you prefer to look at the map before the walk, you can first familiarize yourself with the templates in the third part of the book, and then consider the examples as their illustration. If you prefer to take a walk first, and then look at the map where you have been, then first read the first two parts with examples and refer to the third part for inquiries as necessary. Some of the reviewers of this book, noted that the examples are absorbed better if during the reading run the development environment, type the code and run the tests.

Regarding examples, I want to note the following. Both examples, multicurrency computing and testing infrastructure, may seem extremely simple. There are more complex, defective and ugly solutions to these very same tasks (I personally have repeatedly had to deal with such solutions). To make the book more like reality, I could demonstrate one of these solutions. However, my and, I hope, your goal is to write clean code that works. Before blaming the excessive simplicity of examples, for a few seconds imagine a programming world in which all the code also looks clean and clear, in which there are no overly complex solutions, only problems that seem too complicated only at a glance. Difficult problems need careful thought. TDD will help achieve this.

»More information about the book can be found on the publisher's website.
» Table of Contents
» Excerpt

For Habrozhiteley a 25% discount on the coupon - Beck