Skip to main content

Using events to improve testability and reduce temporal coupling.

Temporal coupling in code is usually not very obvious but can cause maintainability nightmares. Code is coupled not by direct dependencies but by depending on the state that left behind by another piece of code. Temporal coupling is not something that should be avoided but it should be expressed explicitly. Someone editing your code should be able to see clearly where dependencies lie.

Functional languages solve this problem by not having side effects. Ordering of functions is very clear if you follow the returned values. In OO languages like C# you don't always have this luxury. Side effects can make things difficult for us. In this post I want to show a different approach to solving this problem[more]

In higher level components, for example the presenter in an MVP UI architecture you often find code like this (warning, contrived example with non-production pseudo code ahead):

   1: public void LoadFile( string path )
   2: {
   3:     fileLoadService.FillModelFromFile( path, model );
   4:     if( model.Verify() )
   5:     {
   6:         view.ShowFileNameInTitle( inputFile.Name );
   7:         view.ShowLines( inputFile.Lines );
   8:     }
   9: }

Effectively you’re just sequencing calls here. The only reason for the existence of LoadFile is to make sure that all the functions that actually do anything are called in the right order. When I started writing tests for code like this I started feeling a bit uneasy:

   1: [Fact]
   2: public void ShouldCallModelVerifyAfterFillModel() { //blah.. }
   4: [Fact]
   5: public void ShouldShowFileNameViewWhenVerified() { //blah.. }
   7: [Fact] 
   8: public void ShouldShowLinesInViewWhenVerified() { //blah.. }

I won’t bore you with the details of the tests. Let’s just say that there’s a lot of mockery and some rhino’s. If you’re used to NUnit think [Test] instead of [Fact]. The point I want to bring across here is that I am forced to test the order in which the functions are called. This means I’m testing implementation details. This isn’t optimal. I don’t know if this is an official test-smell but it should be.

But as is ofthen the case it’s not the tests that should be fixed, it’s the code. Tests smells often point out code smells. Actually I don’t care if model.Verify() is called after fileLoadService.FillModelFromFile(). I only care that the model is verified when it changes to a possible unverified state. I don’t care if the filename and lines are shown in the view when it’s verified, I only care that they are updated every time the model changes to a verified state. So the dependencies I care about are kept hidden while I’m testing them indirectly by testing the order of the calls.

Eventually this will get more of a mess. If the presenter grows more of these implicit dependencies will show up and start conflicting with each other. Sequences like this will show up in more functions. They will be similar but different and hard to maintain.

Events to the rescue!

What we want here is to be notified by the model when it needs to be verified and when it changes so that the display needs to be refreshed. I’d write more code for you but I think this is best illustrated with a sequence diagram.

Here is the original situation where the presenter does all the work:


And here is how we can make this better, the model fires events and the presenter reacts. Coupling between expectations on the state of the model and the reaction by the presenter are made explicit here.


This will cause me to write tests like these:

   1: [Fact]
   2: public void ShouldVerifyOnModelVerifyRequired() { //blah... }
   4: [Fact]
   5: public void ShouldDisplayTitleWhenModelChangesVerified() { //blah... }

I don’t know about you but I find this a lot clearer. The tests reflect requirements instead of implementation. The logic in the presenter is also partitioned better and is easier to reuse.


Popular posts from this blog

Square One available on the Android market

This is just a short post to let you know that a first version of the Android app I’ve been working on for the last couple of weeks is available on the Android market. The app is called Square One and it’s a simple bassline synthesizer. It’s free so try it out and let me know what you think of it, but be prepared it’s still an early version. I hope to add more features in the next few months and maybe build something that can be used to create real music.The lower part of the screen contains the sequencer controls that can be used to program your own bass lines. On the left is a four by four grid of buttons where you can select a step in the sequence. On the right you can select the note to be played on that step. When you’re done you can press Start and the sequence starts playing. The knobs on the top can be used to control a couple of parameters from the synthesizer engine that creates the sound. You can control the cutoff frequency and resonance of the low-pass filter, attack and …

Running a Git repository on Ubuntu using Gitosis

20I’ve been using Git for a couple of small projects that I’ve been hosting on but version control for my bigger ‘secret’ projects still runs on a windows machine with visual svn server.Now that I’m starting to use Mono for a couple of projects so I’m playing with linux more. Last week I decided to try to try out gitosis on an ubuntu server. I found out it’s pretty easy to use when you know your way around git but for a noob like me some things weren’t immediately clear. Eventually I solved most problems I ran into, so I decided to write up the steps I took to install gitosis on ubuntu 10.04

The big move

People who visit here more often probably noticed that my blog has been down a couple of times the last few months. The problem was that after giving up on hosting it on an (expensive!) windows server I tried unsuccessfully to host my blog on Ubuntu with Mono. I could probably get this to work but it takes too much time and effort. So I decided to move to a hosted blog on Blogger. This way I can spend more time blogging and less time on blog administration.If you’re on a stylish white blogger page right now you’re already on the new blog. Have fun and expect most of my old content to appear there over time. If you’re on my old coffee themed blog you’ll probably need to move to Or you can wait. As soon as I have all my content moved over I’ll point to the new blog too.