Let’s imagine, that we test a controller method - isolated peace of
code with a well-defined responsibility: treat request and produce
response (and may be also authorize user). We set up our mocks and
stubs, i.e. doing minimal setup for running single method.
And what we have? Test fails because view-file called methods of your
model, which you did not mocked or stubbed. So, we have to setup
UNNESSESARY stub-methods/mock-expectations because of code, which has
no meaning during the test. As a result, our nice simple test code
grows up to a unreadable monster.
Does anyone have experience with solving this problem?
On 19 Aug 2008, at 11:33, Daniel V. wrote:
grows up to a unreadable monster.
Could you stub the render method ? (don’t you want to know if there’s
a typo etc… in your view?)
Fred
Daniel V. wrote:
Does anyone have experience with solving this problem?
You have way too many mocks. The “minimal setup” rule does not mean “set
as few
of your real objects up as possible”.
It means that the fewer mocks you must use, and the fewer objects you
must setup
to test something, the more clean, lean, and decoupled your code is.
Expensive
setup is a design smell, and mocks are more expensive than production
objects.
All your objects should be ready to work in a minimal state without
extra work
to set them up.
You should only mock expensive things, such as hardware, random numbers,
the
system clock, etc.
Leave your mocks in this test, and (if you use Mocha) use Mocha’s
any_instance
to whack the model methods you can’t bear to call. Then, in your next
test, turn
on the fixtures you need to truly test, and call everything without any
mocks.
TDD is not “unit testing”, which is a Quality Control concept of
mission-critical applications. TDD is about serendipitous cross-testing
of many
features out of each test case. Unit tests with overlapping units are
bad; TDD
with overlapping units is good.
–
Phlip