Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do.
-- Steve Jobs

Tuesday, September 6, 2011

Making a Mockery of TDD | Virtuous Code

Making a Mockery of TDD | Virtuous Code
I made this gnomic remark on Twitter the other day:
To be a successful mockist, you must dislike mocks.
A lot of people re-tweeted it, so I guess I’m not completely alone in thinking this way.
I should back up a bit. A “mock object”, or “mock”, is a specific kind of test double. It is an object used in a Unit Test which stands in for another object, and carries certain expectations about how what methods will be called, and how they will be called. If the expectations are not met, the test fails. By contrast, other test doubles, such as stubs objects, make no assertions about which methods will be called. This article is specifically about mock objects and mocked methods, which make an assertion about when, how many times, and with what arguments certain collaborator methods will be called.
The term “Mockist” refers to those programmers who use mock objects in their unit tests. There is another camp of programmers, called “Classicist” by Martin Fowler, who eschew mock objects entirely in their tests.

No comments:

Post a Comment