测试驱动开发实践：以金钱示例解析

需积分: 9 189 浏览量更新于2024-07-26 收藏 889KB PDF 举报

"Test Driven Development by Example" 是一本由 Kent Beck 所著的经典书籍，主要讲解测试驱动开发（TDD）的实践方法。这本书对于Java开发者来说是必读之作，它深入浅出地介绍了如何通过TDD模式来构建更易读、质量更高的业务应用程序。书中通过实际案例，遵循“测试-编写-重构-测试”的循环流程，帮助读者逐步理解并掌握TDD的核心理念。测试驱动开发是一种软件开发方法论，其核心思想是在编写实际代码之前先编写测试用例。这种方式可以确保软件在开发初期就具备良好的可测试性，并且随着代码的不断迭代，测试用例能够持续验证代码的功能正确性。书中的"MoneyExample"章节展示了如何从一个简单的货币计算问题入手，逐步构建出稳定且可扩展的代码结构。书中涉及到的技术标签包括Java、敏捷开发、JUnit、Mockito等。Java是实现TDD的主要编程语言，而JUnit是一个流行的Java单元测试框架，用于编写和运行测试用例。Mockito则是一个模拟库，它允许开发者在测试中创建和控制依赖对象的行为，以便隔离被测试代码，确保测试的准确性和效率。在TDD过程中，"Refactorings"（重构）是一个关键步骤，通过重构可以改善代码的结构和设计，而不会影响其外部行为。作者还提到了故事化（Story Time）和任务列表（To-do lists），这些都是敏捷开发中常见的管理工具，有助于跟踪项目的进度和需求。 "MoneyExample"中，作者讨论了"Degenerate Objects"（退化对象）、"Equality for All"（所有对象的平等性）、"Privacy"（私有性）以及"Making Objects"（创建对象）等概念。这些话题揭示了在TDD中如何处理基本数据类型、比较操作、访问控制以及对象创建等问题。此外，"Franc-ly Speaking"和"Makin' Objects"章节探讨了货币转换和时间处理等具体场景。 "Apples and Oranges"章节则可能涉及不同类型或类之间的比较，这在多态系统中是非常重要的。"Mixed Currencies"和"Abstract Currencies"章节则可能深入到如何处理多种货币的混合计算以及抽象化设计。这本书通过实例详细阐述了TDD的方法和好处，包括提高代码质量、降低维护成本、促进团队沟通等。同时，它也涵盖了敏捷开发的实践，如持续重构、用户故事和测试自动化，这些都是现代软件开发中不可或缺的技能。对于希望提升自己软件开发能力，特别是对TDD感兴趣的开发者来说，这本书提供了丰富的知识和实践经验。

CHAPTER 1 Story Time

Early one Friday the boss came to Ward to introduce him to Peter, a prospective

customer for WyCash, the bond portfolio management system they were selling.

Peter said, “I’m very impressed with the functionality I see. However, I notice you

only handle US dollar denominated bonds. I’m starting a new bond fund and my

strategy requires that I handle bonds in different currencies.” The boss turned to

Ward, “Well, can we do it?”

Here is the nightmare scenario for any software designer. You have been cruising

along happily and successfully with a set of assumptions. Suddenly, everything

changes. And the nightmare wasn’t just for Ward. The boss, an experienced hand at

directing software development, wasn’t sure what the answer was going to be.

WyCash had been developed over the course of a couple of years by a small team.

It was able to handle most of the varieties of fixed income securities commonly

found on the US market, and a few exotic new instruments, like Guaranteed Invest-

ment Contracts, that the competition couldn’t handle.

WyCash had been developed all along using objects and an object database. The

fundamental abstraction of computation, Dollar, had been outsourced at the begin-

ning to a clever group of programmers. The resulting object combined formatting

and calculation responsibilities.

Story Time

For the last six months, Ward and the rest of the team had been slowly divesting

Dollar of its responsibilities. The Smalltalk numerical classes turned out to be just

fine at calculation. All the tricky code for rounding to three decimal digits got in the

way of producing precise answers. As the answers got more precise, the compli-

cated mechanisms in the testing framework for comparing to within a certain toler-

ance were replaced by precise matching of expected and actual results.

Responsibility for formatting actually belonged in the user interface classes. As the

tests were written at the level of the user interface classes, in particular the report

framework

, these tests didn’t have to change to accomodate this refinement. After

six months of careful paring, the resulting Dollar didn’t have much responsibility

left.

One of the most complicated algorithms in the system, weighted average, had like-

wise been undergoing a slow transformation. At one time there had been many dif-

ferent variations of weighted average code scattered throughout the system. As the

report framework coalesced from the primodial object soup, it was obvious that

there could be one home for the algorithm, in AveragedColumn.

It was to AveragedColumn that Ward now turned. If weighted averages could be

made multi-currency, the rest of the system should be possible. The heart of the

algorithm was keeping a count of the money in the column. In fact, the algorithm

had been abstracted enough to calculate the weighted average of any object that

could act arithmetic. You could have weighted averages of dates, for example.

The weekend past in the usual weekend activities. Monday morning the boss was

back. “Can we do it?” “Give me another day and I’ll tell you for sure.”

Since Dollar acted like a counter in weighted average, in order to calculate in multi-

ple currencies they needed an object with a counter per currency, kind of like a

polynomial. Instead of 3x

and 4y

, though, the terms would be 15 USD and 200

CHF.

A quick experiment showed that it was possible to compute with a generic Cur-

rency object instead of a Dollar, and return a PolyCurrency when two un-alike cur-

rencies were added together. The trick now was to make space for the new

functionality without breaking anything that already worked. What would happen if

Ward just ran the tests?

1. For more on the report framework, see c2.com/doc/oopsla91.html

After adding a few un-implemented operations to Currency, the bulk of the tests

passed. By the end of the day, all the tests were passing. Ward checked the code

into the build and went to the boss. “We can do it,” he said confidently.

Let’s think a bit about this story. In two days, the potential market was multiplied

several fold, multiplying the value of WyCash several fold. The ability to create so

much business value so quickly was no accident though. Several factors came into

play:

• Method—Ward and the WyCash team needed to have constant experience

growing the design of the system little-by-little, so the mechanics of the trans-

formation were well practiced.

• Motive—Ward and team had to understand clearly from the business the impor-

tance of making WyCash multi-currency, and to have the courage to start such a

seemingly impossible task.

• Opportunity— The combination of comprehensive, confidence-generating tests;

a well-factored program; and a programming language that made it possible to

isolate design decisions meant that there were few sources of error, and those

errors were easy to identify.

You can’t control whether you ever get the motive to multiply the value of your

project by spinning technical magic. Method and opportunity, however, are entirely

under your control. Ward and his team created method and opportunity by a combi-

nation of superior talent, experience, and discipline. Does this mean that if you are

not one of the ten best software engineers on the planet and you don’t have a wad of

cash in the bank so you can tell your boss to take a hike, you’re going to take the

time to do this right, that such moments are forever beyond your reach?

No. You absolutely can place your projects in a position for you to work magic,

even if you are a programmer with ordinary skills and you sometimes buckle under

and take shortcuts when the pressure builds. Test-driven development is a set of

techniques any programmer can follow, that encourage simple designs and test

suites that inspire confidence. If you are a genius, you don’t need these rules. If you

are a dolt, the rules won’t help. For the vast majority of us in between, though, fol-

lowing these two simple rules can lead us to work much closer to our potential:

• Write a failing automated test before you write any code

• Remove duplication

剩余238页未读，继续阅读

dykskaly

粉丝: 0
资源: 11

测试驱动开发实践：以金钱示例解析

Kent Beck的测试驱动开发实战

Python实现TDD演练：模仿《测试驱动开发》示例

Kent Beck的Test-Driven Development实战

py-tdd-by-example:使用 Python 的 Kent Beck 在“Test Driven Development by Example”中给出的示例演练

Test-Driven Development By Example

Test Driven Development: By Example

aw - test-driven development by example

Test-Driven Development by Example.rar

Test-Driven Development by Example - Kent Beck

Test Driven Development, A J2EE example

最新资源