Working Effectively With Legacy Code — Changing Software (Part 1: Chapter 3)

This is Chapter 3 of the Working Effectively With Legacy Code series. If you haven’t read Chapter 2.

Part 1 : Mechanics of Change:

Episode 3: Sensing and Separation

Generally, when we want to get tests in place, there are two reasons to break dependencies: sensing and separation.

1. Sensing: We break dependencies to sense when we can’t access values our code computes.
2. Separation: We break dependencies to separate when we can’t even get a piece of code into a test harness to run.

In legacy code the big problem is dependency. When we want to execute a piece of code and see what it does, there’s always dependencies on other code. This other code is what triggers the effects of our actions in the piece of code. These other pieces of code are often called Test Doubles.

Different kinds of Test Doubles

Fake Objects:

A fake object is an object that impersonates some collaborator(dependency) of your class when it is being tested. They have actual working implementations, but usually take some shortcut which makes them not suitable for production.

An example, can be an DAO or Repository object implementation which talks to database. The fake objects doesn’t talk to database, but will return some fake data, and typically impersonates the real DAO or Repository object.

Mock Objects:

‘Mock Objects’ are special case objects that mimic real objects for testing. The insist upon behavior verification. These objects are pre-programmed with expectations which form a specification of the calls they are expected to receive.

Dummy Objects:

These are objects that are passed around but never actually used. Usually they are just used to fill parameter lists.

Stubs:

They provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. They use state verification. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects.

Spies:

Are studs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.

Chapter 2: Legacy Series

Working Effectively With Legacy Code — Changing Software (Part 1: Episode 2)

Chapter 4: Legacy Series

References:

• Working Effectively With Legacy Code~ Paperback
• Software testing ~ Wiki
• Mocks aren’t stubs ~ MartinFowler
• Fakes, Mocks and Stubs ~ Pragmatis Blog
• Test Doubles ~ Gerard Meszaros