Chris Holmes Online

Sometimes, when a film is based on literary source material, like a novel or short story, it is enough to get the broad strokes right; to get the soul of the story correct at the exclusion of minor details. Often, a filmmaker doesn’t have the time or budget to fully realize a complete interpretation of a novel. Other times the source material is simply too big or complex to fit into the narrow frame of a two-hour movie. In these cases a skilled writer/director/producer team can extract the essence of the literary work and translate it to film in a way that is satisfactory and fulfilling to both fans of the original work and moviegoers. Minor details may be left out, but the core – the heart of the work – is maintained.

This is not the case with I Am Legend, the new film from director Francis Lawrence.

I Am Legend is about the life of Robert Neville, the sole survivor of a virus outbreak that has left everyone on Earth either dead or transformed into creatures akin to vampires. By day, Neville roams the empty streets of Manhattan hunting animals for food, pumping gas (to run generators), picking vegetables in a makeshift garden, broadcasting radio messages to anyone who will listen, and trying to find a cure for the virus in a very fancy laboratory that he has setup in the basement of his apartment. At night, he barricades every window, door and potential opening and sleeps in a bathtub with his dog and automatic rifle clutched tightly, the sounds of the howling vampires echoing in the streets.

If this setup sounds familiar to the 1954 Richard Matheson novel that it is based upon, that is because it is. But the setup is where the similarities end. There is a point in the movie where it makes a significant departure from the novel.

I did not read the Matheson’s novel prior to seeing the movie. But I did read the condensed synopsis of the story on the Wikipedia. The Wiki reveals many details of the story that I will not spoil here. However, it does offer one very interesting piece of information about the title of the novel, which in itself reveals much about the primary story:

He (Robert Neville) finally realizes why the new society of the living infected regards him as a monster: just as vampires were regarded as legendary monsters that preyed on the vulnerable humans in their beds, Neville has become a mythical figure that kills both vampires and the infected living while they are sleeping. He becomes a legend as the vampires once were, hence the title.

Unfortunately, while the film retains the title I Am Legend, it does not retain any of the brush strokes from the source material. The film comes to its conclusion via a much different path, and it is not nearly as superior of a story arc as the one Matheson created.

That is not to say that I Am Legend is a bad film; it is not. But it is not what it could have been if only the creators would have stayed true to the heart of the novel. In shaping this version of I Am Legend for the screen, the creators have twisted the meaning of the very words of the title so that by the conclusion of the film they mean something entirely different than what they meant to Matheson’s novel.

Despite the severe deviation from the novel, the film still works on its own. Will Smith does an admirable job in the role of Robert Neville (although Christian Bale might have been a better choice) given that he is asked to carry the film for at least the first hour with only himself, a dog, and the barren city streets of Manhattan. Director Francis Lawrence steals a page from Robert Zemeckis (Cast Away) during this time by significantly limiting the soundtrack, which helps create a very isolated atmosphere.

There are moments during the film where we really feel like we understand Neville and his state of mind. The isolation has affected his sanity, yet we know he’s smart enough to realize this himself, and still he can’t seem to help but talk to the mannequins in the video store he frequents.

If there’s a misstep here (other than deviating from the novel in a significant way) it is the use of CGI to create the vampires. They look fake. The clearly artificial villains hinder the film; they take something that feels very real and terrifying and pull us back a bit to remind us that what we’re watching isn’t real at all, which is disappointing considering that some recent films (The Descent, 28 Days Later) were much better done without all the CGI monsters.

I Am Legend feels like a film that should be better than it is. It is the third time that Matheson’s novel has been made into a movie. It is by far the best film version of his story, but a far cry from being the “charm”.

I got into software development because I wanted to make video games. That didn’t work out, but I stayed in software development because I enjoyed the idea of being able to enact immediate change in my work. Software is soft, and that means we can improve it today, tomorrow, next week or next year. And we can see the results of our improvements immediately; we don’t have to wait for the cement to harden, we can just hit “Build”.

But quite often there are barriers to enacting change and improving design, and often those barriers come in the form of customers.

Agile development teaches us to be flexible: we utilize clean designs with clear separation of concerns so that we can refactor our code as necessary to meet the changing demands of the customer; we use proven patterns and practices so we can stay out of dangerous waters; we use nifty tools to help increase our productivity. But the thing that doesn’t get talked about enough is the inflexible customer.

There’s a phrase where I work that crops up in just about every conversation we have with our customer: We’ve always done it that way. That phrase has has single-handedly added more lines of code and more complexity to this project that anything else I can think of. It has destroyed our ability to simplify our design. It has lengthened our development time considerably.

And it has ripped out my heart.

I love software development – when it is software development. What I don’t enjoy is having the customer rigidly dictate the design of an application based on some pre-existing paper process and then making sure to squash every effort to improve the workflow or the software by repeating the mantra, “But we’ve always done it that way.”

I can honestly say nothing kills my excitement – nothing quenches my fire – faster than, “We’ve always done it that way.” I imagine it is like staring at a hideous mess of code and having someone say, “You are not allowed to touch that – don’t refactor that at all – we’ve always written code that way.”

I’m curious to know what other developers do to survive a customer like this. What keeps your passion afloat when you’re presented with this situation? I’m having to fall back on Personal Pride and Work Ethic. And honestly, I hate those guys. Yeah, they get the job done, but they’re so much less pleasant to be around than, say, Passion and Excitement.

CAB comes with a default implementation for handling state called the State bag. However, it’s not a particularly good implementation. Part of the problem with the CAB state bag is that it’s not strongly typed; it’s basically a glorified Dictionary. When you retrieve an object from the State bag you do this:

Employee employee = (Employee)State["SomeKey"];

Since I started using CAB, I’ve avoided using the CAB State bag. I remember a hallway chat with Brad Wilson during last year’s Patterns & Practices Summit, where Brad basically said, “Yeah, we wish we would have had time to remove the State bag from CAB before it shipped, but the schedule didn’t allow it.” Brad’s advice was to roll our own State service if we wanted to handle state.

For a while, our shop functioned without a State service and without relying on the State bag. One solution we initially tried was to dump objects into the WorkItem’s Item collection. This is not much better than the State bag, but it does have the advantage of being typed. However, it makes unit testing a pain because now your Presenter class is dependent on having a WorkItem injected into it for unit testing purposes. I don’t like those sorts of dependencies when I unit test – I like to test classes in bare isolation with mocks.

A second solution we used was to simply hold on to objects via private member variables in Presenter classes:

public class SomeViewPresenter : Presenter
{
   private Employee _employee;
   private IPayrollService _payrollService; 

   [InjectionConstructor]
   public SomeViewPresenter([ServiceDependency] IPayrollService payrollService)
   {
      _payrollService = payrollService;
   }

   [EventSubscription(EventTopicNames.LoadEmployee, ThreadOption.UserInterface)]
   public void LoadEmployee(object sender, EventArgs e)
   {
      _employee = _payrollService.GetEmployee(e.Data);
   }
}

This is simple, but creates its own pain during testing. When you use private member variables to hold on to references to objects, you have to ensure that whatever method in your Presenter is responsible for fetching the business object from its source (like LoadEmployee) must be called prior to calling the method you’re really interested during testing, because you have to be able to load the private variable with an actual object. This is awkward, to say the least. Not to mention that it precludes us from doing any sort of sophisticated state management, like undo/reset.

For testing purposes, wouldn’t it be better if we could just call the method we’re really interested in testing, and not have to initialize or load the Presenter? And isn’t maintaining model state outside the scope of the Presenter anyway? It’s job is coordination, not state management.

To solve these problems I gravitated toward the creation of an IStateService and an ApplicationClosingEventHandler delegate. The interface and delegate are listed below:

public delegate bool ApplicationClosingEventHandler(IList unsavedChangesNotification);

public interface IStateService
{
   void SetState(string key, object obj);
   T GetState(string key);
   T Undo(string key);
   bool Remove(string key);
   bool ContainsKey(string key);
   bool HasUnsavedChanges();
   IList UnsavedChangesNotifications { get;}

   event ApplicationClosingEventHandler ApplicationClosing;
}

The implementation is as follows:

public class StateService : IStateService
{
   protected IDictionary _state = new Dictionary();
   protected IList _unsavedChangesNotifications;

   public virtual void SetState(string key, object obj)
   {
      if (_state.ContainsKey(key))
      {
         throw new ArgumentException("An item with the same key has already been added to the StateService.");
      }
      else
      {
         using (MemoryStream buffer = new MemoryStream())
         {
            BinaryFormatter formatter = new BinaryFormatter();
            formatter.Serialize(buffer, obj);
            Memento memento = new Memento(obj, buffer.ToArray());
             _state.Add(key, memento);
         }
      }
   }

   public virtual T GetState(string key)
   {
      return (T)_state[key].Item;
   }

   public virtual bool ContainsKey(string key)
   {
      return _state.ContainsKey(key);
   }

   public virtual bool Remove(string key)
   {
      return _state.Remove(key);
   }

   public virtual T Undo(string key)
   {
      T obj;

      using (MemoryStream buffer = new MemoryStream(_state[key].ByteArray))
      {
         buffer.Position = 0;
         BinaryFormatter formatter = new BinaryFormatter();
         obj = (T)formatter.Deserialize(buffer);
      }

       _state[key].Item = obj;
      return obj;
   }

   public virtual event ApplicationClosingEventHandler ApplicationClosing;

   public virtual bool HasUnsavedChanges()
   {
      _unsavedChangesNotifications = new List();
      bool hasUnsavedChanges = false;

      if (ApplicationClosing != null)
      {
         foreach (ApplicationClosingEventHandler handler in ApplicationClosing.GetInvocationList())
         {
            bool result = handler.Invoke(_unsavedChangesNotifications);

            if (result)
               hasUnsavedChanges = true;
          }
      }

      return hasUnsavedChanges;
   }

   public virtual IList UnsavedChangesNotifications
   {
      get { return _unsavedChangesNotifications; }
   }
}

The StateService has two main parts: state management and gathering unsaved changes notification. The first part, the state management, works similar to the Memento pattern you’d find in GoF. There’s a SetState, GetState and Undo (Reset), which will place your object back into the state it was in when you last called SetState. This is not n-level undo: it’s just 1-level undo because that’s all we need right now. But you could tweak it to support n-level undo pretty easy I think.

The StateService achieves the 1-level undo by taking a “snapshot” of the object when SetState is called. It then serializes the object to a binary stream and stores it, along with a reference to the actual object, in a “memento” class (not a true Memento pattern as you would see in GoF because we don’t ask objects to provide their own mementos, but the idea is similar). Of course, since it uses serialization it expects your objects to be Serializable. If you didn’t want that, you’d have to provide a different implementation. But since most objects that require state management are probably serializable already, this seems a logical fit.

The second part of the StateService is gathering unsaved change notification. Now, you may wonder: why do we need the delegate when we could just iterate through the list of objects we’re already holding in the StateService, and if they inherit from some base class (which ours do) then we could just cast them to the base class and check a “dirty” flag and know if there were objects in an unsaved state. But we added the delegate because we wanted interested classes (Presenters/Controllers) in our application to be able to return a message telling the user where those unsaved changes are located within the UI, so the user can quickly find them and make the necessary saves. You might think this is overkill or unnecessary, but you haven’t had to write code for our users

Thus, the StateService publishes an ApplicationClosing event which interested controllers/presenters in the UI layer can subscribe to. When the user goes to shut down the application we listen for that event (at the Shell level) and ask the StateService if it has any unsaved changes. The StateService queries all it’s listeners and if there are any unsaved changes then we can halt the application from closing and throw up a MessageBox with the list of messages from the event handler.

So why all the fuss with the service? The advantage here is that the StateService can easily be mocked via a tool like RhinoMocks. State management now becomes the responsibility of the StateService, and not the Presenter. We’re able to separate those concerns, which helps us focus on testing the real responsibilities of the Presenter, which is typically coordination between the model and the view.

It’s not the most awesome solution, I’m sure, but it serves our needs. And since this is a topic that continues to crop up in CAB circles, I thought I’d post our way of doing things.

One of the tenets of the Agile Manifesto reads:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The past few days have been one of those opportunities. In part because of the way our workload was structured, but also because of pain.

For a long time we’ve been using stubs to perform unit testing. This works, but comes with a certain level of baggage. That baggage can turn into pain; pain that can grow over time as the project increases in size. Our project has grown sufficiently large enough that the pain has become more acute, and so we started looking at alternatives.

Through Google, I ran across this post from Alex McMahon. Alex was also using stubs, and wondered if a mock framework would be better. He enumerates the benefits of a mocking framework quite well in his post. The point that he made that resonated the most with me was this:

Decoupling of tests – by not using a single hand coded mock we will avoid coupling tests together by sharing a single mock.

When we started unit testing, this was the road we went down as well: hand-coded stubs. We created stub classes with preloaded data for testing, and then we used those across the suite of unit tests. You can probably imagine the pain that sort of coupling eventually caused.

Using stubs for unit testing equates to state-based unit testing. A typical unit test will involve doing something like fetching a stubbed business object or DTO from a stubbed service, manipulating the stubbed object (like adding an item to a list), and then fetching that stubbed object off a stub view, and asserting a value (for instance, a count).

Problems occur whenever the data for a stub class changes; maybe because of some new requirement for a new test case, or because someone needed additional data for a particular test. Every time the stub data changes it can affect other unit tests and test fixtures. You can try and mitigate that by creating different subsets of the same stub classes with different suites of data, but that becomes a lot of work very quickly.

Coupling unit tests to a hard-coded stub is a bad thing. It might not look like it early on, but as your application grows and requirements change, the problem becomes compounded. This coupling makes tests brittle. Brittle tests are the tools of the devil – they erode developer confidence, which is exactly the opposite of what we’re trying to achieve with unit testing.

With that in mind, I decided to take a look at RhinoMocks. I read Oren’s blog every day through my aggregator. His blog is a great window into the mind of a great developer, so I knew RhinoMocks would rock. It’s also free. And from what I heard while at the ALT.NET conference, RhinoMocks was pretty widely adopted (as was TypeMock).

The first thing you have to get past when switching from stubs to a mocking framework is the syntax. It’s just different. But very quickly it starts to read clearly – much more clearly than a stubbed test fixture. Tests become easier to understand and you can figure out the meaning of a unit test much faster when you can read something like this:

Expect.Call(service.GetEmployee(6)).IgnoreArguments().Return(employee);

Other than the new syntax, the biggest change is switching from state-based testing to interaction-based testing. And I have to say, after some time with RhinoMocks I enjoy the interaction-based testing much better.

Take, for instance, the following test. We want to ensure that a service call is made and a list of Department names is fetched and then passed to the view for binding to a drop down list. To achieve this with stubs, we have to have concrete stubs for the Service & View, and we have to assert the object off the View to make sure it reached its destination. More complicated logic might also test the count of a list, or specific data values on the object that the view contains.

[Test]
public void OnViewReady_FetchesDepartmentNamesFromService_AndUpdatesView()
{
   IPayrollService service = new Stubs.PayrollService();
   IDepartmentsView view = new Stubs.DepartmentsView();
   List departmentNames = new List();
   service.DepartmentNamesDTOReturnValue = departmentNames;

   DepartmentsViewPresenter presenter = new DepartmentsViewPresenter(service);
   presenter.View = view;

   presenter.OnViewReady();

   Assert.AreEqual(departmentNames, view.DepartmentNames);
}

This ends up being a very simple test. But as you begin to test more complicated logic, your asserts quickly grow in number and complexity. Frequent assertions include testing to make sure list counts meet some expected value, or specific fields have certain values.

Imagine testing a list’s Count property to ensure a new item created by the user was added to the list. Now imagine a few days later a fellow developer adds a new item to the default stubbed list. All of your unit tests will fail now because the count will be off by one in the stubbed list.

These problems happen because we’re using state-based testing to verify that a method call or an event publication/subscription actually occurred. It is a roundabout way to perform unit testing on classes that don’t need to worry about state. And this is where interaction-based testing shines.

The same test in RhinoMocks looks something like this:

[Test]
public void OnViewReady_FetchesDepartmentNamesFromService_AndUpdatesView()
{
   MockRepository mocks = new MockRepository();
   IPayrollService service = (IPayrollService)mocks.CreateMock(typeof(IPayrollService));
   IDepartmentsView view = (IDepartmentsView)mocks.CreateMock(typeof(IPayrollService));
   List departmentNames = new List();

   DepartmentsViewPresenter presenter = new DepartmentsViewPresenter(service);
   presenter.View = view;

   
   Expect.Call(service.GetAllDepartmentNames()).Return(departmentNames);
   view.DepartmentNames = departmentNames;
   LastCall.On(view);
   

   presenter.OnViewReady();

   mocks.VerifyAll();
}

What’s great about the RhinoMocks version is that it reads like how you think the program logic should execute. I expect GetAllDepartmentNames to be called with no parameters. I expect the list of DepartmentNameDTO’s to be returned when that call is made. I expect the DepartmentNames property to be set on the view. I don’t care what the list of DTO’s looks like, how much data it has, what the list count is or anything else. Only that methods get called and properties get set.

My test is not dependent on any external classes – everything is mocked for my by RhinoMocks. The test is self-contained. Changes to other tests in this test fixture – or any other test fixture for that matter – won’t cause this test to break. It’s not brittle anymore.

The benefits to this become apparent when you start using the mock framework for more complicated tests, because you can eliminate all data that is state-based and just worry about the flow of the logic. Did the right methods get called? In the right order? The right number of times? Did an event get wired up correctly? Did an event get fired? Caught? Did methods that are not supposed to be called get called? Do I even care?

RhinoMocks lets you ask these questions and answer them in a way that is direct and intuitive.

And, of course, for classes where you do still need to do state-based testing, RhinoMocks lets you do that as well.

Overall, I’m extremely pleased we’ve started using RhinoMocks. I’m more pleased that we’ve moved on from state-based unit testing in classes where it’s not necessary. In short: I’m sold.