book

Test Driven Development: By Example

by Kent Beck

November 2002

Intermediate to advanced

240 pages

5h 9m

English

Addison-Wesley Professional

Read now

Unlock full access

Courage

What’s Next?MetaphorJUnit UsageCode MetricsProcessTest QualityOne Last Review
Test (noun)Isolated TestTest ListTest FirstAssert FirstTest DataEvident Data
One Step TestStarter TestExplanation TestLearning Test1Another TestRegression TestBreakDo OverCheap Desk, Nice Chair
Child TestMock ObjectSelf ShuntLog StringCrash Test DummyBroken TestClean Check-in
Fake It (’Til You Make It)TriangulateObvious ImplementationOne to Many
AssertionFixtureExternal FixtureTest MethodException TestAll Tests
CommandValue ObjectNull ObjectTemplate MethodPluggable ObjectPluggable Selector3Factory MethodImposterCompositeCollecting ParameterSingleton
Reconcile DifferencesIsolate ChangeMigrate DataExtract MethodInline MethodExtract InterfaceMove MethodMethod ObjectAdd ParameterMethod Parameter to Constructor Parameter
How large should your steps be?What don’t you have to test?How do you know if you have good tests?How does TDD lead to frameworks?How much feedback do you need?When should you delete tests?How do the programming language and environment influence TDD?Can you test drive enormous systems?Can you drive development with application-level tests?How do you switch to TDD midstream?Who is TDD intended for?Is TDD sensitive to initial conditions?How does TDD relate to patterns?Why does TDD work?What’s with the name?How does TDD relate to the practices of Extreme Programming?Darach’s Challenge
Feedback

Content preview from Test Driven Development: By Example

Chapter 32 Mastering TDD

I hope to raise questions here for you to ponder as you integrate TDD into your own practice. Some of the questions are small, and some are large. Sometimes the answers are here, or at least hinted at here, and sometimes the questions are left for you to explore.

How large should your steps be?

There are really two questions lurking here:

How much ground should each test cover?
How many intermediate stages should you go through as you refactor?

You could write the tests so they each encouraged the addition of a single line of logic and a handful of refactorings. You could write the tests so they each encouraged the addition of hundreds of lines of logic and hours of refactoring. Which should you do?

Part of the answer ...