"...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.
Doh! Im sorry I missed that. :(
In any case, it's a great reference link. thanks for posting it :-)
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.
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.
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.