Friday 2 April 2010 vs MSpec?

For my personal projects I use MSpec as a testing framwork. MSpec had it's advantages and disadvantages. Here is an example of a test I wrote.
   37 public class When_setting_the_state_of_a_host
   38 {
   39     private static HostCheckResultCommand command;
   40     private static HostCheckResultCommandHandler commandHandler;
   41     private static IRepository _repository;
   42     private static Host _host;
   44     Establish context = () =>
   45     {
   46         _host = new Host("asterix");
   47         _repository = MockRepository.GenerateMock<IRepository>();
   48         _repository.Expect(x => x.GetById<Host>(""))
   49                    .IgnoreArguments()
   50                    .Return(_host);
   51         _repository.Expect(x => x.Add<Host>(null)).IgnoreArguments();
   52         command = new HostCheckResultCommand("asterix", HostState.Up);
   53         commandHandler = new HostCheckResultCommandHandler(_repository);
   54     };
   56     Because of = () => commandHandler.Execute(command);
   57     It should_have_a_HostStateChanged_event = () => ((IEventProvider)_host).GetChanges().First().ShouldBeOfType<HostStateChanged>();
   58     It the_event_should_have_HostState_Up = () => ((IEventProvider)_host).GetChanges().First<HostStateChanged>().NewState.ShouldEqual(HostState.Up);
   59 }
MSpec has a lot of advantages:
  • Once you are used to lambda expresions, it is relative easy to read.
  • Since every test is in it's own class, tests can't conflict with each other.
  • Every test statement (It) is named and run even when another test statement failes.
  • Everything in the class should be static, since the use of anonymous functions.
  • Can be difficult to get started.
At work I started using as testing framework.
    1 public class A_Person : XPODatabaseTestFixture
    2 {
    3     [Fact]
    4     public void can_be_created()
    5     {
    6         Person person = ObjectSpace.CreateObject<Person>();
    7         Assert.NotNull(person);
    8     }
    9 }
Well we don't compare the tests, because they are completly different, but we can compare the frameworks.
The main advantages xUnit.Net has are:
  • Every test is performed isolated, for every test method a new instance of the object is created.
  • The test runner is very fast, tests are run in different threads, multiple at a time.
  • Can use the constructor for common setup and IDisposable for teardown. (Setup and teardown contain logic that is run before and after each test. other frameworks use the [Setup] and [Teardown] attributes)
The only disadvantage I found in both (and other) test framework is that there is no VisualStudio testsrunner provided. You either need to use the extenal test runner they provide, or a tool like Testdriven.Net, Resharper or DevExpress Coderush.

Although I like MSpec very much, I am going to dump it for With I don't have to think about making my members static.

Friday 19 February 2010

CQRS the simple way.

CQRS stands for Command Query Responsibility Segregation and is a pattern that splits an application into two parts: Commands and Queries.
Queries are used to get data from a datasource (like a database) and commands are used to do something with the data.
The simplest form of CQRS is the following:

public interface BlogQueryService
    IEnumerable<Blog> GetAllBlogPosts();
    Blog GetBlogPost(int blogid);
    IEnumerable<Comment> GetAllCommentsForPost(int blogid);

public interface BlogCommandService
    void NewBlogPost(string title, string text);
    void EditBlogPost(Blog editedBlog);
    void AddComment(int blogid, string comment);

The BlogCommandService just updates the datasource with the given data (and does validation if needed) the query service just return simple data.
Of course this is not scalable and a lot of advantages that Udi Dahan and Greg Young describe are not here, but it is a first step to decouple a lot of applications.

Monday 15 February 2010

Make development easier and faster with unit testing

As software developers we always come across bugs, some bugs are not very difficult to fix and other bugs are more difficult. Sometimes it is even hard to find the place in code where the bug is coming from and sometimes when we fix a bug we introduce several other without knowing it.
The solution for this problem are unit tests.

Another problem we have is that the user wants to know that the software (s)he is using is reliable. We as software developers should be able to tell the user that the software we are writing is reliable. And we should be able to tell that we have implemented features the way the user wants it and not the way we think they want it or should use it. Basically the user is king.
The way to get some reliability is unit testing.

So what are unit tests?
A unit test is code that is testing the software we have been writing or are going to write. You can test software on multiple levels.
First we can test functions/methods directly like this:
public int Add(int x, int y)
    return x + y;

public void TestAdd()
   int result = Add(2, 3);
   Assert.AreEqual(5, result);
Second you can test bigger parts of the system:
   1:  [Test]
   2:  public void When_playing_files_that_donot_exist_give_error()
   3:  {
   4:      ProgramPlayer player = new ProgramPlayer();
   5:      try
   6:      {
   7:         player.Play("filethatdoesnotexist.mp3");
   8:         Assert.Fail("Exception was not thrown");
   9:      }
  10:      catch(FileNotFoundException ex)
  11:      {
  12:          Assert.IsNotNull(ex);
  13:      }    
  14:  }
And you can test complete usecases and programs.

For most people it seems like wast of time to write unit tests. When I first started with unit tests it was like I wasted time (although at that time I was at university), but after some time and a lot of improvements I realized that unit testing does help. Last year I had to write code for some really difficult calculation. A colleague made the calculations on paper so that I could validate it.
So I wrote some tests for all those calculations and I started to work out a solution.
I soon found out that is was easy to split up the solution in multiple parts, so I wrote unit tests for each part of the solution as well and soon I had a working implementation.
At that moment I didn't even have a user interface to test it in. I found out that working with unit testing is much faster than without. You can test specific parts of the program very fast without the need of starting the application and navigate to the place where you are using the feature you are testing.

Thursday 7 January 2010

Refactor spagethi Form code to something usefull

There are a lot of applications that are very difficult to maintain. The original writers would not always agree about that statement, but others will see their code as an unmanageable mess.
I will not blame the original writers of those applications. A lot of them started with software development as their hobby or out of interest. During time they learned some "best practises" by reading tutorials about how to write desktop applications using forms (like in Visual Basic or Delphi). These tutorials tell you that in the event handlers you put the code that should be run when somebody presses a button or when an item is selected. There are even components like timers that could let you do stuff at specific times / intervals.
For tutorials this is OK and I did it as well, but I realised that it is plain stupid to do so. The problem is that you get large chunks of code within event handlers and forms. At some point it will be difficult to know where some piece of code can be found. Is it on FormA, FormB or (even worse) on both?

In the rest of this post I want to describe some small steps to re-factor to easier to maintain and understand code. As an example I use a simple application to manage data from media files. There is a form that add/edit music, it has a save button and  a close button.

Get code out of event handlers.

The first step is to get event handlers as small as possible. Put all the code that is currently in the event handler into a method and call that method in the event handler. An example:
In the form for adding and editing music information we have a lot of code in the OnSaveClicked event handler. There is code to see whether we are adding or editing the music, there is code to fill the data set (or the sql query, or whatever we are using for persistence) and there is some validation code. That would be at least 15 to 30 rows of code. (depending on how much information we can fill in). By moving all this code to a separate method we can easily call this same method from the OnClosed event handler to let the user save the changes when closing the form.

Split code that is interacting with the controls from other code.

In the method to save the music information we are still asking the information from every input control. So let say we have a textbox to fill in the year of when the music is written, we would call txtYear.Text to get the information. We will probably do this at least two times (one for the validation, because this is a required field and two for saving the value). When we want to change to control to a DateTime control, we have change the code for validation and the code for saving the value which could lead to unexpected behaviour (a.k.a. bugs).
A better way would be to have a method that accepts parameters (one for every field that should be saved). You will then get the following code:
public void OnSavedEvent(object sender, EventArg e)

private void SaveMusic()
    string name = txtName.Text;
    // int year = Int32.ParseToInt(txtYear.Text); // we used a textbox but now we have a special control called YearPicker which gives back an integer.
    int year = yearPicker.Year;
    string composer = txtComposer.Text;

    SaveMusic(name, year, composer);

private void SaveMusic(string name, int year, string composer)
    // do a lot of stuff with name, year and composer
This way we can easily change a control without worrying about whether something goes wrong with saving the data.

Separate concerns.

To be honest, I don't like to much knowledge within a form. A form is there to display data and to handle input and  a little but for orchestrate the application flow (more on this in a later post).
Doing stuff with data (and getting the data) could better be done in a separate class. So we can create a class called MusicDataService, which has the SaveMusic(string name, int year, string composer) method. It will also get some methods to load the data.
public struct Music
    public string Name;
    public int Year;
    public string Composer;

public class MusicDataService
    public void SaveMusic(Music music) {/* lot of stuff to be done... */ }
    public Music GetMusicWithName(string name) {/* lot of stuff to be done... */ }

public class MusicAddView()
    private MusicDataService _service = new MusicDataService();
    public void OnSavedEvent(object sender, EventArg e)
    private void SaveMusic()
        Music music = new Music(); = txtName.Text;
        music.year = yearPicker.Year;
        music.composer = txtComposer.Text;
Now that we have the knowledge of saving music separated from it's form, we can use the same code at multiple places if we want.

Smaller methods.

As I said the SaveMusic method in the MusicDataService contains a lot of logic. It validates the input and it makes sure that it gets persisted. Since validation on it's own can contain a lot of code, it is recommended to put this in a separate method as well. This gives us an other advantage. We can now validate the Music structure multiple times even when we don't want to save. When editing the object we can directly validate the input and gave the user feedback.
The real implementations of validating and saving data I will not show, since this is very specific for each applications and there are just to much ways of doing it (and frameworks that could be used). This said it is probably a good idea to make that code pluggable, so we can swap the implementation if we want to. (how to do this could be another post.. you can also use google)


In this post I tried to show that using some easy steps it is not to difficult to make your program easier to maintain, easier to test and easier to understand for new software developers. And this all leads to a more solid application.

Thursday 10 December 2009

Excellent post about CQRS by Udi Dahan

Udi Dahan has published an excellent blog post about Command Query Responsibility Segregation. This is a really interesting approach of software development, and I tend to follow that approach in my NetworkMonitoring system.

Wednesday 9 December 2009

The power of patterns

The user interface is one of the most important parts of an application, at least for the end user. It is also the part of the application that will change a lot during the life cycle of an application. Sometimes I even think that you can just make some changes in the user interface and call it a new version of the product and users will be happy.
So to be able to change the user interface without much trouble is a must. But with a lot of applications I saw, this is not possible.What is the problem? The user interface contains to much logic.
This is a problem that many people had and there are some easy ways to solve this...
When a couple of people found the same problem and a solution for it, we can call of a pattern. A pattern is just a description of the solution and not the solution itself, so most of the time you have to modify the pattern a little bit to make it work efficiently in your own situation.

A pattern we can use for our user interface problem is the Model View Controller (MVC) pattern.
In MVC we have the Model which is just the data that is requested by the user. The View is the actual form that shows the data from the Model and it will send actions from the user to the Controller. The Controller is responsible for giving the View the right data and update the Model. When the Model is updated it will send a notification to the View and the View will update itself.

Now  this is a basic and fast description of MVC and there are a lot more (and better) descriptions on the internet and in books ;)

The 'problem' I have with MVC is that the Model sends updates to the view and the view knows a lot of the Model. And I am not the only one, because there is an other pattern called Model View Presenter (MVP) which is basically a decoupled version of MVC. The Role of the Model is the same, but the View only shows data which it gets from the presenter, and it doesn't update anything by itself. The Presenter has a bigger role, whenever an action is performed it should update the data on the view. It could be frustrating, but it makes the view (user interface) easier to understand/change.
Changing the user interface
Using this patterns makes it really easy to change the user interface, we can easily make a new view and add it it to the Presenter. How these are coupled is basically a matter of taste. I tend to go for Dependency Injection, but it is also possible to give the Presenter a little more knowledge and let it create the view manually.
Although I am not sure about it because I never tried it, I think the MVC pattern family make it easy to change from a desktop application to a web application. There will be some changes in the infrastructure, but in the presenters and the models there shouldn't be much differences.
Testing the presenters
Testing the user interface is difficult, and testing logic in the user interface even more difficult. Using the MVC pattern makes it pretty easy to test at least the most of the logic since the logic is inside the Presenter. We can create a simple version of the view to test whether information is send to it and we can use it to see if the events are working.
So the only not tested parts of the system are the actual views, these should be tested by humans because automated tests will be to complicated (although there are tools who can do this...)
When you have a problem and don't know how to solve it, it is great to be able to find a pattern that describes a possible solution. The problem is that you should have seen the pattern before you know that you can use it. That was basically the purpose of this post. I introduced you to the problem of a fat UI and I mentioned a pattern that could solve the problem. But there are a lot more patterns you probably wan to know about. Therefore I want to redirect you to a few sites:

Friday 20 November 2009

To inject or not to inject, that is the question

When trying to implement the specification and implementation for scheduling a check, I had the problem of what method to use for sending the event.
There are basically two options:
  1. Inject a Bus
  2. Use a static/well known object for sending the event.
Lets take a look at both options...

Inject a bus

When Injecting a bus (or an other service) the Host will need a variable/field that holds the implementation of the service. Somehow the real implementation should be injected into the object. Normally we will do that by using a framework like structuremap or some other Dependency Injection framework.
But we have the problem that Host is an Entity which we will not instantiate ourself, but we ask our repository. So there will be another place where we need to inject the right service and I think this will lead us to duplicate code.

Use static object

Using a static object would be much simpler. We have one object that sends all events to the right place. How the event handlers are registered depends on the architecture of the application, but basically this will be done via an Dependency Injection framework. This method is explained more deeply by Udi Dahan.


Injecting services into entities is just to complicated and in my opinion should be avoided.
Using static classes as services should also be avoided, because it will make testing more difficult.

So what do we use? I will choose for the static class, because it only routes the actual events to the right handler, it will be easy to implement and it will be easy to use it in tests. Other services should be non static classes so that it follows the normal object oriented philosophy.

Wednesday 18 November 2009

The host in charge or How to design software the good way.

Software design is something that can be really challenging. This becomes more clear when you are working on a project now and than, or have some very complicated software.
In the last topic I talked about the challenge of defining the scheduler and what it should schedule. I thought it was a good and easy point to start with, but it is not. I think by starting with the scheduler I want to make it much to generic and I don't want to be to generic, I just want it to do what it should do.
To identify what it should do I have to start somewhere else.

The Host.

Within NetworkMonitor hosts play an important role. A host is a network device with a networkcard and an network address.
The state of the host can be checked and set from the outside. The host itself is responsible to notify others that a new check should be scheduled, but the user should be able to schedule a check manually as well.

This above text will leas us to the following design:

The SetState and ScheduleCheck methods will have parameters, but I don't know them yet.
The idea is that when the SetState method is called, the ScheduleCheck is called automaticly.
The ScheduleCheck will fire an event (ScheduleCheckEvent) to schedule the check. The event will contain all the necesary information for others to get the right host, the right check and the right time to perform the check.
Since the host has a public ScheduleCheck methode, the user can also schedule the check whenever he likes.

The Tests

Since this is a learning project I want to start using a Test first approach. This means we start with writing tests and then write the code to let the tests pass.
I am going to use specification style testing which means I write specifications/stories about what I need to test. Here are my specifications for the Host:
Given: an Host
When : ScheduleCheck is called
Then : a ScheduleCheckEvent is raised
Given: an Host
When : the status is set via SetStatus
Then : then a ScheduleCheckEvent is raised
I tried writing specifications before, but I found it always difficult to do. These specifications are as simple as can be. The reason for this (I think) is that I want to test less than before, or made things to complex.

ok, but that is not code.. I am going to use MSpec which is a .NET project for Behaviour Driven style testing.

public class When_scheduling_a_check
   static Host hots;
   Establish context = () => { host = new Host(""); };
   Because of = () => { host.ScheduleCheck(DateTime.Now); };
   It should_have_raised_a_ScheduleCheckEvent;

public class When_setting_the_status
   static Host hots;
   Establish context = () => { host = new Host(""); };
   Because of = () => { host.SetState(State.Ok); };
   It should_have_raise_a_ScheduleCheckEvent;

All that I have done here are writing the When (Establish context) and Then (Because of). The actual test is still pending.
The funny code (() => {};) is part of the .NET syntax and are called lambda expressions. This makes it possible to put functions/methods inside a property to be run at a later moment.

Well thats all for today. I will have to implement this first before I continue :)

Thursday 5 November 2009

Scheduler, what to schedule?

I am thinking about the scheduler part of my NetworkMonitor. On of the things I want to do in the NetworkMonitor is to use a service layer. A service layer is a thin layer between the actual application (executable / user interface) and the domain. and it provide the supported scenarios. In case of Commands Query Seperation, it also provide the commands and their handlers.

Back to the scheduler part... I want to have a SchedulingService which provide all the possible operations for the scheduler. Since I want to use the YAGNI (You Aint Gonna Need It) approach. I only have two methods for this service:
  • Schedule something
  • Do something with the Scheduled things
As you can see this is really vague... What do I need to schedule? Do I schedule Events? Do I schedule Commands? (here commands are a domain specific thing) Do I schedule System.Action?

At this point I just don't know... I think it really depends on how generic this scheduler should be... Should I be able to schedule tasks that are not domain stuff as well? or do I choose to schedule only domain specific stuff.

The solution
Well, since I want to be YAGNI, I think I decide to schedule only domain specific tasks. When a task is scheduled and it is time to perform the task I will fire an event to let some other class know that it should be performed.
It is a good thing to think out loud... You get some solutions that way.

Tuesday 27 October 2009

Commands and Events

In my last post I ended with talking about sending messages between bounded contexts. In this post I want to describe how to do this, but I also want to talk about a new thing I want to try out. It is called Command and Query Responsibility Segregation (CQRS).

Please leave a message to tell me if you understand it or not?

With CQRS you are basically splitting the commands from the queries (Inserts, updates, deletes from the selects :)). This means that we can optimise how we show data on the user interface and how we handle changes.

From the user interface we send "Commands" to the domain. These commands will modify the aggregate roots and save the changes. These changes are translated into "Events" which are saved. When we want to get our aggregate root, we simple have to playback all the events to get our state. This means we have a nice log of what has happened with the object.

An example

"Ok, sounds nice, but how does it work?" you may say.. Lets look at a simplified example:
The user wants to create a new radio program into the system. After clicking on the "New" button, the UI does something like:
_commandBus.Send(new CreateRadioProgramCommand(Guid.NewGuid(), _programName));

In the domain we have a CreateRadioProgramCommandHandler class which will create a new RadioProgram object and save it to the Repository.
While creating the RadioProgram a CreateRadioProgramEvent will be created. This event will be saved in the database and will be published. By publishing the event the event can be used to update the query cache so that the user can find the RadioProgram in the user interface.

Updating the radio

Now that we have a Radio Program, the user can use the user interface to change details of the Radio Program. So when we have changed things, the UI does something like:
_commandBus.Send(new ChangeRadioProgramLanguage(_id, "Dutch"));

The ChangeRadioProgramLanguageCommandHandler will ask the repository for the correct radio program. The repository will get all previous events and use those to construct the Radio Program.
Then the Language will be changed and the Radio Program will be saved.
This causes a new event, LanguageChangedEvent and this event will be published so that the UI cache will be changed.

Communicating with Bounded Contexts?

At this point I am not really curtain how the communication between Bounded Contexts can be established. I think it could be both "Events" AND "Commands" or "Events" that are leading to "Commands"