Unit Testing – Page 3 – BinzBlog

Changing To A More Focused Approach

I remember when I first really understood mock objects. I was working as a developer at Progressive Insurance and all of a sudden it hit me that I could test a method without having to test the objects it called in its work. This seems like an obvious statement, but it takes a little time to sink in to a brain such as mine. Once I got my head wrapped around the mocked object concept I was the proverbial hammer lover looking for nails to pound. What this led to were long, serpentine, and very brittle tests. These tests looked like a negative of the method they were testing, every nook and cranny of the method behavior was brought out, in each test. I was happy since I was able to mock like there was no tomorrow, but something was not right.

Take the example method below.

What I have traditionally done is written a few tests that have names like ‘ProcessOrdersTest’ and run down one full logical path through the entire method. It might have looked something like the below:

The problem with the above is that if anything changes in the method the test breaks. This is good, since I want the test to break, but I don’t know what caused the test to break, since the test is testing so many things. Also, if I have two or three methods like the above to test all code paths then one change can break all the tests. I’ll have perhaps three broken tests without any idea what is breaking them.

What I’ve started to do to mitigate this is to write tests that test one particular thing in a method and ignore everything else. Instead of testing a whole code path what I’ve started doing is making sure my test name states one condition to test, and then I try and test that one condition and relying on as little else in the method staying the same. What that leads to is something like the below, and it seems to be working much better. When a test breaks I have more of an idea as to what has gone wrong, and when I purposefully change things I have fewer tests to update.

I Think I Applied SRP Today?

I came across batch job code similar to the below ( the below is just for an example and far simpler than reality!) that was written to update orders in a database from an xml response from a payment system. The code should do the following:

Load the response into an object we can read the data from.
Get a list of ‘batches’ returned in the data.
Update the batches as received in our database.
Get a list of orders for each batch and update them accordingly in our database.

The original code does what it’s supposed to do but I wished to put unit tests around it. What I found was it was difficult to do because the entry point for my mocks was at the highest level. The class was also doing three things, getting and parsing the payment response, updating a batch in our system and updating orders in our system. If I wasn’t careful tests I wrote to tests that orders are updated correctly could break because of changes to how batches are updated, not good. Continue reading “I Think I Applied SRP Today?”

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

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”