Stories about Software


Mock.Of() and Mock.Get() in Moq

Today, I’d like to highlight a couple of features of Moq that I didn’t know about until relatively recently (thanks to a recent google+ hangout with Moq author, Daniel Cazzulino). Since learning about these features, I’ve been getting a lot of mileage out of them. But, in order to explain these two features and the different paradigm they represent, let me reference my normal use of Moq.

Let’s say we have some class PencilSharpner that takes an IPencil and sharpens it, and we want to verify that this is accomplished by setting the Pencil’s length and sharpness properties:

So, I create a test double for the pencil, and I do some setup on it, and then I pass it into my sharpener, after which I verify that the sharpener mutates it in an expected way. Fairly straight forward. I create the double and then I manipulate its setup, before passing its object in to my class under test. (Incidentally, I realize that I could call “SetupAllProperties()”, but I’m not doing that for illustrative purposes).

But, sometimes I’d rather not think of the test double as a double, but just some object that I’m passing in. That is, perhaps I don’t need to invoke any setup on it, and I just want to reason about the actual proxy implementation, rather than stub.object. Well, that’s where Mock.Of<>() comes in:

Much cleaner, eh? I never knew I could do this, and I love it. In many tests now, I can reason about the object not as a Mock, but as a T, which is an enormous boost to readability when extensive setup is not required.

Ah, but Erik, what if you get buyer’s remorse? What if you have some test that starts off simple and then over time and some production cycles, you find that you need to verify it, or do some setup. What if we have the test above, but the Sharpen() method of PencilSharpener suddenly makes a call to a new CanBeSharpened() method on IPencil that must suddenly return true… do we need to scrap this approach and go back to the old way? Well, no, as it turns out:

Notice the third line in this test. Mock.Get() takes some T and grabs the Mock containing it for you, if applicable (you’ll get runtime exceptions if you try this on something that isn’t a Mock’s object). So, if you want to stay in the context of creating a T, but you need to “cheat”, this gives you that ability.

The reason I find this so helpful is that I tend to pick one of these modes of thinking and stick with it for the duration of the test. If I’m creating a true mock with the framework — an elaborate test double with lots of customized returns and callbacks and events — I prefer to instantiate a new Mock(). If, on the other hand, the test double is relatively lightweight, I prefer to think of it simply as a T, even if I do need to “cheat” and make the odd setup or verify call on it. I find that this distinction aids a lot in readability, and I’m taking full advantage. I realize that one could simply retain a reference to the Mock and another to the T, but I’m not really much of a fan (though I’m sure I do it now and again). The problem with that, as I see it, is that you’re maintaining two levels of abstraction simultaneously, which is awkward and tends to be confusing for maintainers (or you, later).

Anyway, I hope that some of you will find this as useful as I did.

By the way, if you liked this post and you're new here, check out this page as a good place to start for more content that you might enjoy.


Recognizing Test Smells

Tonight, I was plodding through the process of getting to know MongoDB and its java driver, TDD style. This is an interesting experience, as most of one’s development is going to involve technologies with which one is familiar and working out designs. This is classic problem isolation — all of your tools are familiar, and you have only to work out the design itself. In this case, I have two problems – the technology and the design aren’t familiar. In situations like this, it’s even more important to follow your nose when it comes to smells in code or tests, as you’re really flailing around in the dark. These may be the only things that guide a technology initiate to good practice short of taking a class or reading some books (and even then, they’re important, because you can only learn so much without getting your hands dirty.

Read More


Upgrading TFS from SQLExpress

Back Story

Some time back, I setup Team Foundation Server (TFS) on a server machine more or less dedicated to the cause. This was to test drive it to consider it as a replacement for legacy source control, requirements management, deployment, etc. Since it was a trial, run, I opted for keeping setup simpler initially, reasoning that I could expand later if I so chose. As a result, I didn’t bother with Sharepoint setup initially, and I allowed the default installation of a database, which was SQLExpress.

Once I got used to the features of the basic installation, I wanted to test out the more advanced ones, but this has proven annoyingly difficult. Setting up Sharepoint and trying to retrofit it on existing projects was an enormous hassle, and I wound up having to delete my old projects and ‘recrate’ them with Sharepoint. Granted, these were playpen sorts of projects, but there was actual work in them and they were useful — just not primetime. So, losing them would be a hassle. And besides, it’s kind of hard to fully test a system without using it to do something useful.

After letting the dust settle a bit on that annoyance, I decided I’d switch from SQLExpress to SQL Standard to get the full benefit of TFS reporting services (via SQL reporting services). This was another huge pain point, and I’m going to document below what I had to do. Basically, it involved backing up all the SQL Express databases, installing SQL Server 2008 standard, and importing those backups. This guide is by no means comprehensive and there are a lot of moving parts, so this isn’t exactly a walk through, but hopefully it will help save someone at least some annoyance in this battle and maybe shave a little time off. Read More


Behind the Scenes Feed Magic

Very quickly, I just installed a plugin to consolidate subscription through my feedburner account. Basically, my feedburner account will become aware of all subscribers now, including those who simply access daedtech.com/feed or those who use the subscription buttons on the left. As I understand it, this should have no effect on subscriptions whatsoever. Nonetheless, if it does — if anyone finds they’re having trouble with the feeds — please leave a comment and I’ll look into it.

Thanks, and thanks for reading!


The Slippery Scope

Roll Up Your Sleeves

Have you ever stared into a code mess? I don’t mean some little mess, but rather the kind of mess that, as Nietzsche put it, stares back into you if you stare at it for too long. You can almost feel it making you worse at programming. It’s the kind of thing that everyone agrees is a mess with no dissent. It’s the 10,000 line class or the class titled GlobalVariables that houses hundreds of them. It’s the kind of mess that leads to someone having you add a few more lines to that Godzilla class or a few more globals to the mix in order to get things done, and hating yourself as you do it. I think you’ve probably seen it. It’s an experience you don’t quickly forget, and one you may even commemorate with a submission to The Daily WTF.

There are a variety of ways that people respond to this state of affairs. Some will shrug and adopt a “when in Rome” attitude as they blithely break another window in this dilapidated building. Others will refuse to make things worse (at least inasmuch as the group political dynamic allows) without making things better either. Still others will apply the so-called “Boy Scout Rule” toward small, incremental improvements, fixing the application a few squashed globals and factored out methods at a time. But, there is another category of response to this, and it is the theme of my post today. That category is the rolling up of sleeves in an effort to “do this right, once and for all.”

If Some Is Good, More Is Better?

The people who take this latter approach, sticking with the Nietzsche theme, probably consider themselves uber-boy-scouts. Boy scouts aim to leave the code a little better than they find it, but uber-boy-scouts aim to leave the code a lot better. Curiously, however, boy scouts tend to get a lot done over time toward improvement, whereas uber-boy-scouts generally accomplish nothing. What gives? If some is good, isn’t more better?
Read More