以例解析：测试驱动开发实践与改进

需积分: 9 78 浏览量更新于2024-07-23 收藏 689KB PDF 举报

"《测试驱动开发：实例指南》（Test-Driven Development By Example）是Kent Beck所著的一本关于测试驱动开发(TDD)实践的经典著作，由Three Rivers Institute出版，版权日期为2002年。该书以案例驱动的方式深入讲解了TDD方法，其核心理念是通过编写测试用例来引导代码的实现过程。书中提到，作者对Money示例进行了全面重写，目的是改进写作风格，使之更加遵循TDD原则，章节结构更为简洁，语法更贴近国际标准，并减少了美国特有的表达。读者被鼓励对比新旧版本，评估这些改变的效果，是否提升了理解和可读性，以及是否有助于减少技术债务。在阅读过程中，读者可能会遇到需要解释的术语，例如如何构建一个有效的术语表，这可能是TDD中的关键概念，如单元测试、重构等。书中提到的新版如何/为什么重构格式可能与Martin Fowler的其他作品有所关联，但作者提供了指向公共资源的链接，以便读者进一步学习或参考。此外，书中还包含了待办事项列表、章节引言和针对xUnit这类测试框架的使用指导。转换成某种格式（可能是Web框架）的任务也被提及，暗示着技术的持续演进。完成尚未完善的模式（设计模式在TDD中的应用）和突出显示源代码更改也是作者的目标。 Money示例章节可能包含了一些挑战，如如何将实际业务逻辑与测试隔离，或者如何处理某些部分的死胡同。这部分内容强调了在实践中探索和解决问题的重要性，把编程比喻为在黑暗的房子里一间间探寻，而编写测试就像是照明的工具。《测试驱动开发：实例指南》不仅是一本技术教程，也是一本实践手册，它提倡通过实践来掌握TDD，通过测试引领开发，帮助读者提升代码质量，降低维护成本，适应快速变化的需求。阅读这本书时，读者将有机会深入理解TDD的核心思想，并将其应用到自己的项目中去。"

Test-driven development 16 of 133

Money Example

We’ll start with the object Ward created at WyCash, multi-currency money. Suppose

we have a report like this:

Instrument Shares

Price

Total

IBM 1000

25000

GE 400

100

40000

Total:

75000

To make a multi-currency report, we need to add currencies:

Instrument Shares

Price

Total

IBM 1000

25 USD

25000 USD

Novartis 400

150 CHF

40000 CHF

Total:

75000 USD

We also need to specify exchange rates:

From To Rate

CHF USD 1.5

What behavior will we need to produce the revised report? Put another way, what is

the set of tests which, when passed, will demonstrate the presence of code we are

confident will compute the report correctly?

• We need to be able to add amounts in two different currencies and convert the

result given a set of exchange rates.

• We need to be able to multiply an amount (price per share) by a number

(number of shares) and receive an amount.

We’ll make a to-do list to remind us what all we need to do, keep us focused, and tell

us when we are finished:

To do:

$5 + 10 CHF = $10 if CHF:USD is 2:1

$5 * 2 = $10

What object do we need first? Trick question. We don’t start with objects, we start

with tests (I keep having to remind myself of this, so I will pretend you are as dense as

I am).

Try again. What test do we need first? Looking at the list, that first test looks

complicated. Start small or not at all. Multiplication, how hard could that be? We’ll

work on that first.

When we write a test, we imagine the perfect interface for our operation. We are

telling ourselves a story about how the operation will look from the outside. Our story

Test-driven development 20 of 133

Dependency is the key problem in software development at all scales. If you have

details of one vendor’s implementation of SQL scattered throughout the code and you

decide to change to another vendor, you will discover that your code is dependent on

the database vendor. You can’t change the database without changing the code.

If dependency is the problem, duplication is the symptom. Duplication most often

takes the form of duplicate logic—the same conditional expression appearing in

multiple places in the code. Objects are excellent for abstracting away the duplication

of logic.

Duplication also appears in data. Symbolic constants were introduced to eliminate

dependencies between code and magic numbers. Once you use a symbolic constant,

your code is no longer dependent on the actual number. You can change the number

all you want without having to touch the code.

Unlike most problems in life, where eliminating the symptoms only makes the

problem pop up elsewhere in worse form, eliminating duplication in programs

eliminates dependency. That’s why the second rule appears in TDD. By eliminating

duplication before we go on to the next test, we maximize our chance of being able to

get the next test running with one and only one change.

Now back to your regularly scheduled puzzling example.

But where is the duplication? Usually you see duplication between two pieces of code.

Here the duplication is between the data in the test and the data in the code. Don’t see

it? How about if we write?

DollarDollar

intint amount= 5 * 2;

That “10” had to come from somewhere. We did the multiplication in our heads so

fast we didn’t even notice. The “5” and “2” are now in two places, and we must

ruthlessly eliminate duplication before moving on.

There isn’t a single step that will eliminate the 5 and 2. However, what if we move the

setting of the amount from object initialization to the times() method?

DollarDollar

intint amount;

voidvoid times(intint multiplier) {

amount= 5 * 2;

}

The test still passes, the bar stays green. Happiness is still ours.

Do these steps seem too small to you? Remember, TDD is not about taking teensy tiny

steps, it’s about being able to take teensy tiny steps. Would I code day-to-day with

steps this small? No. But when things get the least bit weird, I’m glad I can.

Defensiveness aside, where were we? Ah, yes, we were getting rid of duplication

between the test code and the working code. Where can we get a 5? That was the

value passed to the constructor, so if we save it in the amount variable:

剩余136页未读，继续阅读

ireneyang09

粉丝: 0
资源: 1

以例解析：测试驱动开发实践与改进

测试驱动开发.pdf

测试驱动开发-中文英文.zip

C#测试驱动开发

TDD需求开发人员学习测试相关内容是测试驱动开发吗？

测试驱动开发 单元测试

什么是测试驱动开发？

【判断题】测试驱动开发是由kent beck提出的开发方法

c++程序设计实践与技巧:测试驱动开发 电子书

测试驱动开发 kent beck kindle

测试驱动开发不适合使用C M M和C MM I方法

最新资源

测试驱动开发单元测试

c++程序设计实践与技巧:测试驱动开发电子书