Introduction to "Test driven development"

This book is "Test-driven Development by Example" by Kent Beck[america]. Published by the publishing house, Sun Fong Chung notes.

The following is the translation of this book from my comprehensive English text and comments. A small number of references to Sun Pingping and other people's translation.

Introduced

Back in Friday, the boss went to Ward to introduce him to a wycash potential client, Peter. Wycash is the bond portfolio management system that the company is selling. "I'm impressed by the features I see," says Peter. Anyway, I noticed that you only deal with dollar denominated bonds. I am starting a new bond, and my strategy is to deal with bonds of different currencies. "The boss turned to ward," OK, can we do it? ”

This is a nightmare scenario for any software designer. You are happy and successfully cruising in a set of assumptions. All of a sudden, everything has changed. This is not only a ward's nightmare. The boss, who has extensive experience in directing software development, is not sure what the answer will be.

A small team has been developing wycash for more than one or two years. The system can handle the variety of fixed-income securities that are common in most U.S. markets, and some foreign new tools, such as investment guarantee contracts, that other competing products cannot handle.

Wycash has been developed using object and object databases. In the beginning, the computational function of abstraction, the dollar, is outsourced to a team of smart software engineers. The objects they generate combine formatting and computation.

In the past six months, Ward and other members of the team have slowly stripped off the dollar's responsibilities. The numerical class of Smalltalk is very good in calculation. All the tricky code rounded up to three decimal digits was given the way to produce a precise answer. As the answer becomes more precise, the exact match between the expected and actual results in the test framework replaces the complex comparison mechanism within a certain tolerance range.

The information-formatted operation actually belongs to the user interface class. Because the tests are written at the user interface class level, especially the reporting framework, these tests do not need to be modified to accommodate these changes. After six months of serious cuts, there is nothing left for the operations of the dollar class.

Weighted average, one of the most complex algorithms in the system, has also undergone a slow transition. Over time, many different kinds of weighted average codes are scattered across the system. Just as the reporting framework is merged from the original object, the weighted average algorithm also has a place to hold it, and this place is averagedcolumn.

Averagedcolumn is now the place for ward to start. If the weighted average can support multiple currencies, then the rest of the system should also be available. The core of this algorithm is to keep a certain amount of money in the corresponding column. In fact, the algorithm is sufficiently abstract to calculate the weighted average of any object that can be represented by arithmetic. For example, a weighted average of dates can be calculated.

The weekend passed as usual. Monday morning The boss came back, "Can we do it?" ”

"Give me another day, and I'll tell you the exact answer." ”

The role of the dollar is like a counter in the weighted average. Therefore, for multi-currency calculations, they need an object with each currency counter, just like a polynomial. Only the entries may be USD and 200CHF instead of 3x^2 and 4y^3.

A quick experiment shows that it is possible to return a Polycurrent object when two different currencies are added in lieu of a dollar calculation using a common currency object. The problem now is to make room for new functionality without changing the existing functionality. What happens if Ward runs these tests?

After adding some of the operations that were not implemented for the currency class, most of the tests passed. At the end of the day, all the tests were passed. Ward uploads the code to the system and then goes to the boss. "We can do that." , "he said confidently.

Let's think about the story. Within two days, this potential market is multiplied by several times, multiplied by the value of Wycash several times. The ability to create such a large business value so quickly is not accidental. Many aspects have played a role.

1, Methods--ward and Wycash team need to have some experience, know how to continue to design the system. So the mechanism of transformation can be well practiced.

2. Motivation--ward and his team need to know clearly the commercial importance of building Wycash multi-currency, and have the courage to start such a seemingly impossible task.

3. Opportunities-Comprehensive and blond confidence tests, well-structured procedures, and programming languages that isolate design decisions make only a few sources of error and are easily corrected.

You cannot control whether or not you have the motive to add value to your project by using a technical magic weapon. Methods and opportunities, on the other hand, are entirely under your control. Ward and his team created methods and opportunities by combining super talent, experience, and discipline. Does this mean that joining you is not one of the 10 best software engineers in the world, and there is no money in the bank, so you tell your boss you want a raise, and then you take the time to do it, like this forever is yours?

No. You can put the project in the position of your ability, even though you are a technical general software engineer, you will be mess and jerry-building when you are under pressure. Test-driven development is a technology that any software engineer can understand and encourage to adopt simple design and confidence-enhancing test suites. If you are a genius, you don't need these rules. If you're an idiot, these rules won't help. For the vast majority of us in the middle, following these two principles will enable us to work closer to our potential.

1. Before you write any code, write a failed automated test.

2, delete duplicates.

Exactly how to do this, apply these rules on a subtle level, and you can push these two simple rules to what extent is the subject of this book. We're going to start with the object that Ward created at the moment he was inspired--multiple currency funds.

Introduction to "Test driven development"