..Or ‘Extract and Override’ as it’s otherwise known
Not that it’s specific to CRM, or any particular type of development – indeed, Roy states that he always tries to use this technique first and only defers to other methods of testing if it isn’t possible. I had certain reservations when I first read about it, but having given it a try over the last few weeks I am now a convert.
The purpose of this technique is to insert a ‘seam’ into your code – a place where you can replace dependencies on other classes & services with fake versions, so you can test one class at a time. Previously, I’d always done this using constructor injection, whereby you pass the dependencies into the class constructor:
This way, when we want to test the robot mood logic in KillHumans(), we can create fake versions of IWeaponSystem, ICommunication and IMoodManager, and just test the Robot logic. In the actual system, the real versions of these things would be supplied by a Service Locator/IOC container or similar.
This is all very well, but doesn’t work with CRM because you don’t control creation of classes. Basically you get passed a service and have to use that for all of your communication with CRM. To stay with the robot example, it would look something like this:
Because all communication is going through RobotService.Execute(), it’s very difficult to fake this, especially when it’s called multiple times and you need different return values.
To get over this, we can use Extract and Override. This works by putting the calls to the external services in their own methods, and then overriding them while we’re testing. This way, we don’t have to create fake services at all! Just a single fake version of the class we’re testing. The code in Robot would now look something like this:
Notice that the extra methods are ‘virtual’ so we can override them. they are also ‘protected’ so they’re accessible from classes which inherit from them. So now instead of creating fake services, we’d create a testable version of the robot class, like this:
We now have full control over what gets returned from those methods, and we can record when got sent into them. As such, we can happily test the mood logic in KillHumans() without worrying about those dependencies.
Now, this isn’t limited to the CRM situation described – you can use this technique any time you have a dependency on another service, as an alternative to Dependency Injection. You can read a bit more about it in one of Roy’s blog posts, which probably explains it a bit better! Although sadly without the use of robots.
Handy for Unit Tests – and Much More!
I recently found myself having to type some code in repeatedly while unit testing. This sort of thing:
You can see here that I’ve been using Roy Osherove’s naming convention, which I like a lot. I’m also using the AAA (arrange-act-assert) layout for the test code, which I like to comment for increased readability. Although I’ve done something similar many times, I must have seen something about Code Snippets recently as I thought it might be a good idea to give them a try.
Code snippets are a part of Visual Studio (2008 certainly, not sure about before that). They are little code templates that you can get via intellisense, for example when you type ‘if’:
and then hit ‘Tab’ twice, you get the ‘If template’, with the section highlighted ready for you to put your condition in:
As it turns out, Vis Studio doesn’t ship with a snippet editor, but there is a very good open source one on CodePlexwhich is linked to from MSDN. Using this, I can put in my unit test template, and define the ‘tokens’ that I want to replace (in this case, ‘method name’, ‘state under test’ & ‘expected behaviour’):
I’ve also put in the $selected$$end$ bit, which defines where the cursor goes when you’re done. You can see in this one that I’ve put in a #region for the method name as well – the snipped editor’s smart enough to realise this is the same as the one in the method name. Here I’ve defined the shortcut as ‘ter’ (for ‘Test with Region’), because I don’t like typing.
So save that, and Bob’s your uncle! Go back into Visual Studio, type ‘ter’ (tab-tab), and as if by magic, you very own unit test template appears, awaiting your input!
It’s the type of thing you wish you’d found out about years ago, and I’m sure over the next few days I’ll make about a hundred of these things for increasingly pointless bits of code. But it’s another productivity increase, and they all add up, so if I find a few more of these I’ll be able to write a day’s worth of code in about two keystrokes!
Now I wonder what else Visual Studio does that I don’t know about..