Making your tests withstand design and interface changes - remove code duplication

My blog has moved. You can view this post at the following address: http://www.osherove.com/blog/2005/4/10/making-your-tests-withstand-design-and-interface-changes-rem.html
Published Monday, April 11, 2005 2:29 AM by RoyOsherove
Filed under: ,

Comments

Sunday, April 10, 2005 8:20 PM by Matt Berther

# re: Making your tests withstand design and interface changes - remove code duplication

This looks similar to the ObjectMother pattern [1]. This pattern seems to break things out into a separate object, rather than just private methods to the class.

[1] http://www.thoughtworks.com/us/library/ObjectMother%20Website.pdf
Sunday, April 10, 2005 8:32 PM by Roy Osherove

# re: Making your tests withstand design and interface changes - remove code duplication

Matt: which is why I stated:
"...they should be refactored out into a separate helper class with static helper methods for this creation (also known as the "Object Mother" pattern)."
it's a variation, but still the same concept.
Sunday, April 10, 2005 9:48 PM by Matt Berther

# re: Making your tests withstand design and interface changes - remove code duplication

Doh! Im sorry I missed that. :(
Sunday, April 10, 2005 9:48 PM by TrackBack

# Improving Testability

Sunday, April 10, 2005 9:53 PM by Roy Osherove

# re: Making your tests withstand design and interface changes - remove code duplication

In any case, it's a great reference link. thanks for posting it :-)
Sunday, April 10, 2005 11:05 PM by TrackBack

# Code duplication in tests

Roy Osherove on making your tests withstand design and interface changes by removing code duplication....
Sunday, April 10, 2005 11:26 PM by TrackBack

# New Team System Stuff - 2005-04-11

Visual Studio Team System

Richard Campbell has announced that he and Carl Franklin will tape an episode...
Monday, April 11, 2005 9:04 AM by Paul Speranza

# re: Making your tests withstand design and interface changes - remove code duplication

That is exactly what I do. My unit tests are starting to take on a life of their own. They have become their own subsystem. And a valuable one at that.

For those of you that have not taken the unit test plunge. I have good example of the benefits of unit tests - I had to start creating an API weeks before the UI was even started (by other programmers) so I wrote the API and used the unit tests as my UI.

Once the UI team got started what they got was a well tested API. By using Roy's suggesting of moving code into helpers I was able to reuse the test logic in several combinations, which produced better tests, which caught bugs but required alot less phone calls from the front end team to report bugs.
Monday, April 11, 2005 9:20 AM by Darrell

# re: Making your tests withstand design and interface changes - remove code duplication

Shouldn't the call to your object creation code be in the SetUp method? I would be uncomfortable having the same call to "setupCalculator()" method in ever Test method.
Monday, April 11, 2005 9:36 AM by Roy Osherove

# re: Making your tests withstand design and interface changes - remove code duplication

Darrell: good point.
I think "setUp' starts to break down the more varied tests you have in a fixture.

In this case only the call to the "generic" version of creating the object could be sent to a SetUp method, but that's not the case as the amount of tests grow. Using the SetUp method for initializing an object to a known state only works for simple fixtures or fixtures which only test one feature given a specific state.

Lots of tests need the object in a specific state prior to test start, but lots of other tests need it in a different state at the start. SO - you can't mix and match different start states for differ tent tests.. which leaves you with (to my mind) more readable alternative of setting up state with helpers in your test code. since it's only one line - which you can make as readable as you want - no "hidden" initialization takes place for the specific test - all that should be known to the Innocent test reader is known and visible inside the current test.
Thursday, April 21, 2005 10:18 PM by TrackBack

# New Team System Stuff - 2005-04-11