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 31 Refactoring

These patterns describe how to change the design of the system, even radically, in small steps.

In TDD we use refactoring¹ in an interesting way. Usually, a refactoring cannot change the semantics of the program under any circumstances. In TDD, the circumstances we care about are the tests that are already passing. So, for example, we can replace constants with variables in TDD and, in good conscience, call this operation a refactoring, because it doesn’t change the set of tests that pass. The only circumstance under which semantics are preserved may actually be our one test case. Any other test case that was passing would fail. However, we don’t have those tests yet, so we don’t worry about them.

This “observational equivalence” ...