From “The Art of Unit Testing”:
There are several issues that crop up when using manual mocks and
stubs:
- It takes time to write the mocks and stubs.
- It's difficult to write stubs and mocks for classes and interfaces that
have many methods, properties, and events.
- To save state for multiple calls of a mock method, you need to write a
lot of boilerplate code to save the data.
- If you want to verify all parameters on a method call, you need to
write multiple asserts. If the first assert fails, the others will never
run, because a failed assert throws an exception.
- It's hard to reuse mock and stub code for other tests.
Initial thoughts:
It does take time to roll your own. It also takes time to figure out how the hell to do certain things in your fluent API framework of the year (example articles on the way). It also takes more time (sometimes) to figure out an error reported from a Mock framework.
It's not difficult to write large mocks, it's just the time argument again. And perhaps you've got a production code problem with having such large interfaces.
This is just the time argument again, saving the state and dealing with it is the cost of DIY, but it's not a separate con.
As a classicist mocker, I'm rarely concerned with validating passed parameters.
Mr. Fowler would agree:
”[As a classicist mocker], I really like the fact that while writing the test you focus on the result of the behavior, not how it's done. A mockist is constantly thinking about how the SUT is going to be implemented in order to write the expectations. This feels really unnatural to me.”
The last argument I just don't get. It's just a class, why would re-use be intrinsically hard? I've found it not only easy to re-use diy mocks, in some cases they've been able to grow into more robust classes that become useful in testing contexts outside of unit or integration tests (like semi-automatic exploratory testing or load tests).
tags:
ComputersAndTechnology