Time spent creating mock objects is often wasted. The "T" in
Test Driven Design is just as important as the "D."
Real tests--ones that find bugs--require testing real code.
Emphasizing making fast tests using mocks misses what is most
important: creating code that works in your deployed environment.
If your code passed a unit test using mocks but failed
in a system test, you would get no sympathy from me.
Your shit must work, i don't want to hear about the rest.
This may sound stupid, but things are what they are.
If you have a rule like tests must be fast, and apply
that rule blindly, then you are not paying attention
to what things are, you are just paying attention to
the rule. This causes you to justify dropping testing
in favor of test speed.
For the same reason people say you don't need to test
setters and getters, i don't really find a lot of problems
with incorrect communication with other classes. For
all the pros of the design part of TDD, i still want
to find bugs and to find the "real" bugs you need
to test the real code. If that takes time then it
Favoring mock creation means i am spending considerable time
creating tests that skip about a gazillion failure interaction modes.
That's time i would rather spend on finding real problems
in real code and creating real code to solve real problems.
You want to find problems in unit tests rather then system or
acceptance tests because bugs are much easier to find, reproduce,
and fix in the unit test environment. If it is being said problems
will be found at higher levels of test then i think you can do away
with most unit testing period because you can always make this
I do use mocks, have for many many years, but using mocks
is a last resort for me, not the way to do everything.
The above response is in reaction to:
> Seth Ladd: