Mocking Closed Objects

Recently I ran across a situation where I was using an object from a third party ORM tool that I wanted to mock for unit testing.  The method I wanted to test uses this particular third party object and calls methods on it that interact with our data store.   I just wanted to test my method and ensure it calls this third party object correctly, I don’t want the third party object to actually be called since it would then attempt to do its business of communicating with the application’s data store.  The problem was that the object does not implement any interface I can use to easily mock it through a mocking facility such as rhino mock.  Some mock facilities, such as rhino mock, will let you mock an actual object if the methods you want to call are virtual and can be overridden.  Unfortunately the methods I was interested in aren’t virtual so can’t extend the object and create a child class mock without having the real base methods fire.  This wouldn’t work since it was just those methods I wanted to fake.

I think I came up with a fairly slick solution, and a friend even told me this is the same solution proposed by Robert Martin in his book ‘Working With Legacy Code’, when encountering this situation.   All the classes and code below are only examples, they aren’t the code I was actually working on, there would be too much to explain if I tried to actually use that!

MockClosedClass

The class I want to mock is named ‘UnitOfWork’.  In order to create a type I can use for abstraction I created an interface, ‘IUnitOfWork’ that reflects all the methods in the class that I’m interested in mocking.  Continue reading “Mocking Closed Objects”

Unit Testing A Concrete Template

Batch Job Layout
Batch Job Layout

Spent some time today putting unit tests around some changes I was making to a class that runs a batch routine.  The batch routine is implemented as a class that  inherits from a base abstract batch class.  The base class provides methods for all the pieces parts for running a batch job including an abstract method, ‘ExecuteLogic’, that the concrete implementation is to implement to actually do it’s work.

I’m not sure this is such a good setup, basically the ‘RunJob’ method is implemented in the base class and calls the other base methods in a templated order.  It doesn’t call every method,  ‘SetLoggingMessage’  is a base class method that is often called in concrete implementations of the ‘ExecuteLogic’ method.  Something is weird here, but right now I’m only concerned with testing my changes.  Perhaps I’ll look at a little refactoring later.

Generally I’m looking to test the ‘ExecuteLogic’ method implemented in the concrete batch job.  However, some of the concrete batch jobs have calls in their ‘ExecuteLogic’ routine that call base class methods that write to logs or to a database.  There isn’t an easy way to replace the objects in the base class routines that write to the database and the log with mocks, which makes isolating the ‘ExecuteLogic’ method difficult.   Someone suggesting mocking the base class, essentially mocking the instance itself under test, and having the ‘ExecuteLogic’ method take as a parameter it’s own type and pass itself, allowing us to mock it.  We all agreed this was a bad idea, I thought there would be risk of unintended recursion, others thought it wouldn’t make sense to others looking at the code.

Continue reading “Unit Testing A Concrete Template”

My Unit Testing Path

I remember being shown a scary looking v-shaped diagram in my early days at Andersen Consulting.  I was an analyst and was off in the wilds of western Illinois with a slew of other brand new analysts all learning the Andersen Consulting way of building software.  I recall working in teams of three using os-warp and a RAD UI development tool whose name I didn’t know then and still do not know.  In any case, the v-shaped diagram was an overview of how software was to be built.  Starting from the left one went down the v passing through requirements gathering, functional design, technical design until finally reaching the v-bottom, implement.  The first step back up the other side of the v, was unit testing.  There it was, I didn’t know really what it meant beyond do something to make sure things you just developed at the bottom of the v work!

Continue reading “My Unit Testing Path”

And So It Begins

Having recently returned to the world of the itinerant .net Architect contracting world, I’ve decided to share my learnings and conundrums regarding the world of software development on the Microsoft Stack.  I hope to explore and work out issues regarding pragmatic unit testing and object orient design.  One thing I’ve learned through the years is that in software very little is right or wrong, but there are a whole lot of things that can make the experience better or worse.