15 January 2007

to mock or not to mock

i'm not a huge fan of mocks (interaction testing), preferring instead to test behavior. mocked tests don't survive refactoring very well and i despise passing information as strings. currently, i need to test how a certain class in my system launches external process, which i've tossed behind an interface to enable dependency injection.

i had chosen to mock this interface in the test since a sham instance would require nothing more than strongly-typed expectations. (why re-write something that already exists?) in the process, i had to write my own array equality matcher (i.e. i discovered that it doesn't already exist). as i sit now to write my own method invocation action, i realize that a custom sham would have been sooooooo much easier to work with.

i've started writing mock tests five or six times now in this project, but i seem to re-realize each time that mocks suck. at least for the way i prefer to write tests. i am now attempting to codify my thinking so that i'll remember the next time i'm tempted to mock.

No comments:

Post a Comment