Click or type ~ to show Console
Type Ctrl-C to close console. Type 'wat?' to find out how this console was created.
Welcome to the Iloggable Interactive Console. You can navigate posts either by file hierarchy with cd [path] or via paged posts lists using the posts [page] command. You can navigate to a new post with the go [path|#id].


A place to keep my thoughts on programming

August 23, 2009 .net , , ,

Moq rocks

Ok, so i’m not proud of it, but i’ve been a hold-out on mocking frameworks for a while. With the auto-gen of interfaces that resharper gives me, i’d just gotten pretty fast at rolling my own mocks. Once or twice a year, i’d dip my toe into a mocking framework, find its syntax frustrating and rather than get a good used to it, I’d soon find myself replacing NotImplementedException in a stub for yet another custom Mock object.

My reasoning was that if i can roll my mocks just as fast as wiring up a mock, then why bother with the dependency. And I thought I wasn’t really causing myself too much extra work.

In the meantime, I even wrote a simple Arrange/Act/Assert mocking harness for Dream, so i could better test REST services. So, it’s not like i didn’t believe in the benefits of mocking harnesses.

Well, for the last couple of weeks, I’ve been using Moq and it’s pretty much killed off all my desire to roll my own. I’m generally a huge fan of lambdas and have gotten used thinking in expressions. Although even with that, I wasn’t able to get comfortable with the latest Rhino.Mocks. Probably just me. But from the very first attempt, Moq worked like i think and I was up and running.

var mock = new Mock();
mock.Setup(x=> x.Bar).Returns("bar").AtMostOnce();
var foo = mock.Object;

I’m a convert!

Leave a comment