So, back to blogging… (the whole moving, changing jobs, losing boxes, and generally throwing my life in disarry made expounding on topics an admittedly lesser priority) in the past week or so, I’ve looked into Moq, mostly on the basis of it being the newer, cleaner, super-awesome mocking framework. I’d played with Rhino Mocks in the past, so I did have some baseline for comparison. However, in this case, time and ease was of the essence-I was using this on a real project in which nobody else knew mocking, so quick rampup and ease of explainability were key. Maybe not the best time to pick up an unfamiliar tool, but… uh, no time like the present and all, I suppose. I figured since a testing framework is only used on the test side and the production code is not dependent on it (please, don’t split hairs about testing code being production code, I know it sort of is, but that’s not the way I mean) that the risk was a manageable level. I went out, and set up tests using mocking for all repositories, and for internal utilities.
Moq sure is different from Rhino Mocks. The basic idea of mock as stub-type thing is preserved, but the actual usage is very different. In Rhino Mocks, you declare a repository for the mocking framework, get an object from it that fits your interface, and then record a bunch of calls onto it. Later, you set the mode to play, then run your test code. Finally, you can verify that all the calls you set up were actually used. This record/play model takes a bit of time to understand, and to see what it’s for. In contrast, Moq does away with the special mocking repository, and the who record/replay stuff. Sounds really easy, right? Not so fast. Moq uses lambdas/delegates to set up the calls on the mock object. Lampdas are a pretty new feature, (thus still new to a lot of people) and one of the less-easiliy-readable-to-a-newbie- features I’ve come across in .Net. I’d say they’re up there with regular expressions in terms of initial incomprehensibility. Worse, I am restricted to implementing using VB.Net on this particular project. If you thought lambdas were weird with C#, they’re even worse in VB. I’m a bit worried that I may have introduced a *big scary* thing into this project with using these VB lambdas. We’ll see if I’ve shot myself in the foot or not here.
Another item of note about this is that is is actually the first time I’ve used mocks in a real project and not just toy projects at home….(old projects sans interfaces could probably be TypeMocked, but not regular mocked without a whole lot of destruction) It changes the whole project, pushes into the dare I say “modern” way of developing. This project is essentially greenfield, so there was some oportunity to set things up the way I needed. This may be obvious, but interfaces really are key. You use an interface, you can mock. No interface… well, it’s going to be a whole lot tougher. The other thing, you have to be able to inject your mocks to use them instead of the regular classes. So… poof, project gets DI. Once you’ve got things heading that way, your constructors explode. I have the feeling I’m going to get some pushback on those. So, if your repositories are mocked, and various utilities are mocked, you end up with a constructor with 8 things in it, and some of those have constructors with a bunch of things… yow! Which brings in (hopefull) an IOC container to manage the madness. It’s a waterfall of cause/effect. Is all that worth it? Well, you get a lot more flexibility and significantly more granularity in testability. But what if 95% of developers have no clue about IOC/mocks/DI- these concepts are not only somewhat unknown/advanced, but are genuinely tough to wrap your head around-you’ve just wounded your maintainability through no fault of the technology itself. Still worth it? I can’t really say.