"...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.