Brendan Enrick

Daily Software Development

HudsonSC January 2010 Recap

Last night we had a great HudsonSC meeting. People started showing up around 5:30, and I had the opportunity to meet and talk with a few new attendees during that time.

Lightning Talks

At around 6:00 we got things started. Kevin Kuebler started us off with an interesting talk on BDD where he showed some interesting code using MSpec. As usual, he was unable to keep his talk under 10 minutes. We will not fault him for that though, since he discussed the topic well and showed some cool code.

Following Kevin’s talk, we had a well-timed talked from Yasir Drabu about the Unit of Work pattern, which I in no way pressured him into giving at the last minute. Yasir let us know that he was currently implementing this, and he would show us the eventual implementation at a later meeting.

Open Spaces

Our open space discussions start at the same time pizza arrives, so people can sit around eating pizza and discussing interesting topics. The selected topics of the evening were “How to promote agile practices at your workplace” and “Automated build processes”.

I’ll defer to someone else about how the agile practices open space went, but I do believe the build processes discussion was interesting. Continuous integration, build automation scripts, and database change management were the hot topics of discussion among that group.

Coding Exercises

As usual we finished up the meeting with some time spent pair programming through some coding exercises. This time we took our second group attempt through our customized version of KataPotter.

We had a few interesting solutions to the exercise, and each one handled the optimization for getting the price down differently. They all seem to work effectively according to the unit tests. I know my solution was very different from the previous one I used to solve this exercise.

In Northeast Ohio? Come to HudsonSC the third Wednesday of each month in Hudson, Ohio.

My First CodeMash

As a late adopter of CodeMash I can say that version was a great event. There were hundreds of developers there ready to learn and try new things. The intelligent, interesting people sparked many worthwhile conversations. If you’re in the area around Sandusky, Ohio, I highly recommend that you attend the next CodeMash.

Not Your Everyday Conference

I was very pleased with how things were handled with CodeMash. It didn’t feel like the standard “sit in your seat while someone talks at you for an hour”. I really think that involving people is the best way to spread knowledge. One of my favorite quotes touches on this perfectly.

Tell me and I forget. Teach me and I remember. Involve me and I learn.

I can’t say what it was like at every session at CodeMash, but the sessions I attended tried to include the audience when possible.

Software Craftsmanship Workshop

CodeMash has a precompiler the day before the event. The precompiler is a day with two time slots of four hours each. Steve Smith and I ran a workshop during that timeslot. Our Software Craftsmanship workshop went very well. We started by introducing everyone to the concept of Software Craftsmanship. At the end of the day I like to boil this down to people caring about writing good, clean software.

So how does one get better at writing good, clean software? Practice.

  • Write something small and write it well.
  • Try new approaches to a known problem to see if you can improve upon it.
  • Follow along with a known good solution and understand how someone else solves things.
  • Take some bad code and refactor it again and again.

In case you haven’t guessed the goal of our workshop was to give people some practice as well as show them how they can practice on their own in the future.

We started with the Bowling Game Kata from Uncle Bob Martin.  First we went through the slides discussing at each step what he was doing and why he was doing it. This is a great exercise because it lets you see what Uncle Bob does when he hits a wall and needs to back up. At one point in the Kata he realizes that the path he is going down is not correct. This shows you how to identify this situation and then how to resolve it.

After this quick introduction we had everyone dive in with their favorite language attempting to calculate the score of a bowling game.

We continued on with some other exercises including: discussion of followed by implementation of a Supermarket Pricing system and we ended with a bit of fun with FizzBuzz.

I hope those who attended enjoyed the experience, and I welcome everyone to come by our Hudson Software Craftsmanship meetings which meet on the third Wednesday of the month in Hudson , Ohio.

Coding Dojo

This year CodeMash also had a Coding Dojo dedicated to these exercises. Instructions were provided explaining the requirements of the exercises. Some are katas like the bowling game and others exercises to challenge you with creating a good, clean solution to a relatively simple problem.

We recommended people work in pairs with someone they didn’t know, but we had a few people working solo.

Sara Ford stopped by the coding dojo and it seems had a beef with my overuse of the word “kata”. If you’re interested, Steve Smith wrote an interesting response discussing coding katas. The bowling game is a kata to be followed along with and matched exactly. The more closely and exactly that one can match how UncleBob does the kata the better. Some of the other challenges presented there I probably should have titled as “exercises”. Next year, I’ll make sure to have more time to prepare the coding dojo. I hope to see you there.

CodeMash 2010 is this week

logo-codemash I will be attending a great regional event this week. The event is called CodeMash and it is located in Sandusky, Ohio. As the CodeMash site describes it.

CodeMash is a unique event that will educate developers on current practices, methodologies, and technology trends in a variety of platforms and development languages such as Java, .Net, Ruby, Python and PHP.

I hope everyone attending has a safe trip there and has a good time. I look forward to seeing you there. You’ll find me at the Precompiler Software Craftsmanship workshop as well as at the Coding Dojo, which will be open Thursday and Friday in the Banyan room.

I look forward to seeing you all there. If you don’t make it out this year, there is always next year. Have a great week everyone!

My 2010 ASP.NET MVP Award

Today I received an email that has started this year off very well. Microsoft has honored me by re-awarding me with an MVP award in the area of ASP.NET this year. Thank you Microsoft.


Congratulations! We are pleased to present you with the 2010 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in ASP/ASP.NET technical communities during the past year.

I intend to continue working towards a better community. I hope everyone else is as well.


Brendan Enrick | Static Mocking with JustMock

Brendan Enrick

Daily Software Development

Static Mocking with JustMock

One of the coolest (and scariest) things I’ve seen lately is mocking static classes and methods with JustMock. I was working on some legacy code, and was making some changes, so I wanted to make sure that I got everything tested first. When I went to write the tests, I noticed that I needed to wrap and hide away a static method that was being called.

My eventual intent, however, is to get rid of the static class and method calls if possible. Writing the wrapper around it temporarily, so I can get tests in place before refactoring has always seemed like a pain. I went to check and see if JustMock would be able to mock a static class. That seemed like one of those crazy things that commercial mocking frameworks can usually do. I was right. It could mock the static class. (SCARY!!)

I wrote some code that looked like this: (Sorry I can’t show you my clients’ code in my blog without their permission, so you get sample code.)

public static class MyStaticClass
    public static int DoSomeDependentStuffThatIsHardToFix()
        // Pretend this does more than just returning 1
        return 1;


In my example, I need to test some code calling this static method. Normally, I would put a wrapper around this class, write my tests, refactor, and eventually change this to not be a static dependency anymore.

I decided to try this. Here is a test class that uses mocking to demonstrate how I can decide any result for this method and have control of this dependency. Notice that my method always returns 1. Pretend that a different result were possible.

Now when I go to write my test, I can just Mock out the static and define that I want that method to be called and for it to return 2 instead of 1. I will then assert that it worked as I expected in my test. Once I confirm that the mock works as expected using this type of test, I can put it in place in my actual test. (Yes, I sometimes write temporary tests to confirm what I expect before I write the whole test. Little steps.)

public class MyTestClass
    public void WhatIsTestedDoesNotMatter()
        Mock.Arrange(() => MyStaticClass.DoSomeDependentStuffThatIsHardToFix()).Returns(2);
        Assert.AreEqual(2, MyStaticClass.DoSomeDependentStuffThatIsHardToFix());

Then when I go and run my tests, I get this nice result showing me that everything is working as I expect it to. Yippee!

JustMock Static Test Passing

How it achieves this? I am not sure. I intend to find out though. When I do, I will write a post explaining it.

Have a good day!

Comments (4) -

  • Ken

    3/24/2012 10:34:42 AM | Reply

    I looked at this a while ago and I think you should have stressed the fact that if you have to mock something static you generally have a design flaw. I mean you mentioned that this was legacy code and you plan to refactor but when I watched Telerik's demo on it they made it sound like it was the missing link of Mocking which it isn't. The reason mocking frameworks (Moq, Rhino) don't mock static methods is because they are generally a bad design decision.

    That aside - I think a great blog post would be "Look Mom! No ctor, when static classes make sense!".

  • Brendan Enrick

    3/25/2012 6:39:57 PM | Reply

    @Ken Yes, I completely agree. The time to use these is when there is a design flaw with the code.

    The cool thing about this, however, is that I was able to test the code before doing the refactoring. I try to make sure that I test my code before refactoring. Occasionally, I need to make minor changes.

    This lets me test earlier, since I don't have to refactor the static yet. Without the ability to mock the static, I would have needed to refactor without unit tests.

  • Erik

    3/27/2012 3:08:27 PM | Reply

    I've never used JustMock before (I use Moq), but I've recently been doing some stuff in Java and using a tool called PowerMock.  The setup code you have there is similar enough to PowerMock for statics that I wonder if one didn't use the other as a rough API guideline.

    I definitely agree with the "scary" part.  I think that a lot of people who favor static/procedural code will look at this and conclude that there's no downside to using static if you can just 'mock' it out for testing.  There's something good about the pain of trying to test a codebase with a lot of statics -- like the sting of antiseptic on a cut.

  • Eli

    3/27/2012 3:39:41 PM | Reply

    I think the actual reason that Moq and Rhino don't mock statics is because they're based on Castle. TypeMock Isolator stood relatively alone for a while in its ability to mock these types of things because it actually intercepts calls as they are occurring and redirects them (I can't speak to JustMock, I haven't looked into it).

    That said, I'd be interested to know if you tried this to mock an extension method (or better yet, an extension method on an interface).