Mocks, Fakes, Stubs - why bother?

Ever wondered why there are so many different names for the objects that mimic behaviour of the 'real' objects in a system - mocks, stubs, fakes, doubles...

I can't help looking at the tables of definitions on this page and think why bother!

Why have all these mocking frameworks gone and raised the bar of understanding for people who don't like TDD or who don't currently do TDD. To me everything is a mock if it's not the real thing - pure and simple. So when I write tests I call everything a 'Mock' so the tests are easy to read & understand by the anyone (including people adverse to TDD). Prehaps this is one of the reasons why I've stopped using mocking frameworks in general.

I'm sure some people think the distinction between a stub and mock is important but it isn't, the test is important not what & how you mock.



Awkward Coder

Read More

Distributed Systems are Coupled - Period!

If you're doing distributed systems development your systems will be coupled together - period! You can't get away from this statement it's a fact of life. Now how much you're coupled is another question.

After the revelation I had last week that most REST systems aren't REST at all and are in fact just over-elaborated RPC (oh look we've reinvented CORBA again!) - link. I've come to the conclusion that REST systems aren't easy to implement and anyone who tells me otherwise doesn't know anything about distributed systems!

If REST systems were as easy people would make you believe why are so many not classed as REST by Dr. Fielding...


Awkward Coder

Read More

Devlicio.us boys run out of duct tape!

trying to reply to a blog about duct tape programmers and guess what ;)




Awkward Coder

Read More

Test Harnesses are counter productive...

How often do you hear:

'Why do I need to write tests when I've got a perfectly good test harness?'

Now I hear this often and I'm not surprised anymore when I hear it, it's a sign of a dis-functional team where team members don't value the team they only value their output.

I've highlighted the words that give it away:

'Why do I need to write tests when I've got a perfectly good test harness...'

There is no 'I' in 'TEAM'!

Anyone who insists test harnesses are just as good as automated tests is plain wrong.

They're selfish developers who only care about the code they've written - and probably don't get involved with the team. The reason it's selfish is because they might well be able to test all edge cases with their test harness but how is anyone else meant to know how to achieve this. They can't unless they understand exactly how the test harness is constructed and to be used. It's more productive from a team point of view for everyone to write automated tests that are run automatically on checkin & build.

Now more than likely the people who refuse the accept TDD methods are either 'duct tapers' or 'old timers' who in general are past their sell by date anyway - if you can't accept knew ideas then you are definitely in the wrong industry.

At all the 'old timers' - do doctors still regularly recommend leaches?



Awkward Coder

Read More

So you thinking you're doing TDD?

I work freelance and like most freelancers I change job relatively frequently so therefore I do a lot of interviews. One thing I've noticed when being the interviewee is the amount companies lie!

One of the common technical lies I hear is 'We use TDD, all code is under test and we run automated builds...'

I use to take this at face value - being a trusting fellow and not wanting to judge someone to quickly ;)

So if I want to know how much truth is in the statement I could follow up by asking about mocking frameworks, BDD & Dan North etc...

But the killer question for me is to ask about their usage of an IoC container. Now IoC containers have nothing to do directly with TDD but If you're doing TDD you'll be using Dependency Injection and therefore you'll at least considered using one when you've realised your classes start to have to many constructor arguments.

So if they dismiss the usage of IoC without a good reason I know they aren't telling the truth about TDD - it's acceptable not to use IoC in an application you just have to be able to justify it, like every other decision one makes in development.



Awkward Coder...

Read More

I know nothing moments...

I was researching RESTful APIs today, it's couple of months since I worked on a RESTful project and I'm thinking of doing a small project with a RESTful API.

I discovered this link and found out that all my previous RESTful APIs aren't really RESTful ;)

So after discussing this on Yahoo groups I feel like I know nothing about REST now :(


Feeling stoopid now...


Awkward Coder

Read More

The secret all developers should know...

Dave Laribee gives away the secret ingredient!

http://codebetter.com/blogs/david_laribee/archive/2009/09/08/the-secret-sauce.aspx

nuff said...

Awkward Coder

Read More

How to test a static dependency used inside a class...

This is a question that keeps coming up and I know if you're practicing it's a no brainer but I keep getting asked this by devs (I'm no testing God!).

The long answer is to read this book and pay attention when talking about 'inserting a seam'.

The short answer is carry on reading...

Now several people (read Jimmy Bogard) have already answered this but here is my take on this looking at my current client, they have a lots of deeply nested static dependencies - these are implicit dependencies and what you really want to is explicit dependencies because they are easily testable.

So I see a lot of classes like this nested deeply in some object graphs.

 public class Foo
   {
       private string _url;
       private string _connectionString;

       private string _user;

       public Foo()
       {
           _url = System.Configuration.ConfigurationManager.AppSettings["SomeUrl"];
           _connectionString = System.Configuration.ConfigurationManager.ConnectionStrings["SomeConnectionString"].ConnectionString;

           _user = System.Security.Principal.WindowsIdentity.GetCurrent().Name;
       }

       public void Bar()
       {
           // Do something...
       }
   }

So this has 2 static dependencies that are hidden and hard to test...

How do I make this easier to test and remove the hidden dependency?

The answer is I insert a seam for each static dependency - this involves pushing the static dependency behind an interface and expose the properties & methods

So instead of using the ConfigurationManager and WindowsIdentity directly in the code we use an interface that's injected via the constructor.

 public class Foo
   {
       private readonly IProvideConfiguration _configuration;
       private readonly IProvideUserInfo _userInfo;

       public Foo(IProvideConfiguration configuration, IProvideUserInfo userInfo)
       {
           _configuration = configuration;
           _userInfo = userInfo;
       }

       public void Bar()
       {
           // Do something...
           var user = _userInfo.UserName;

           var url = _configuration.Url;
           var connectionString = _configuration.ConnectionString;
       }
   }

   public interface IProvideUserInfo
   {
       string UserName { get; }
   }

   public interface IProvideConfiguration
   {
       string Url { get; }
       string ConnectionString { get; }
   }

Now because I've created two seams - IProvideUserInfo & IProvideConfiguration these can easily be mocked out and testing becomes a lot easier!

So the implementation of these interface would probably look like this:

public class ApplicationConfiguration : IProvideConfiguration
   {
       public string Url
       {
           get { return System.Configuration.ConfigurationManager.AppSettings["SomeUrl"]; }
       }

       public string ConnectionString
       {
           get { return System.Configuration.ConfigurationManager.ConnectionStrings["SomeConnectionString"].ConnectionString; }
       }
   }

   public class WindowsIdentity : IProvideUserInfo
   {
       public string UserName
       {
           get { return System.Security.Principal.WindowsIdentity.GetCurrent().Name; }
       }
   }

So hopefully some people will find this helpful....

Awkward Coder

Read More

Application auditing - an example why I don't work at the weekend...

Ever had a situation where you're OLTP requirements are impeded by your OLAP implementation, well to put it another way - have you ever come across an auditing solution that causes transactions to timeout when you're trying to save data into your production database.

Well the answer for me is far to often for my liking and this is an example of 'synchronous auditing' and I believe this is an anti-pattern in the making. I'm firmly in the camp that believes auditing should be done asynchronously by a different (application) process. The reasons why I think it's an anti-pattern is because, if how you audit affects the performance of your production database then your performance is going to degrade overtime, and if you insert 500,000 audit records a day that's going to occur relatively quickly. Now DBAs would say lets put a maintenance plan in place to clear down\manage the audit database, or even remove the synchronous auditing and perform a batch load once a week out of normal days operation - AT THE WEEKEND OR AFTER HOURS...

I'm not going to support a such a process or help out when such a process fails to bring the production system back online because the batch load failed - MY WEEKENDS ARE FOR ME...

I design auditing systems that allow production-time maintenance of OLAP databases with no affect to OLTP databases and this is achieved by asynchronous auditing via transactional message queues.

You design your application such that when you need to create an audit record for a user\system action you write this to a message queue transactionally as part of the behaviour (business requirement). There is then another independent process monitoring & processing the audit records (in the message queue) into the OLAP database, it's important this process can be controllable so that it can be disabled when ever the OLAP database requires maintenance, i.e. DURING WORK HOURS NOT AT THE WEEKEND. Whilst the process is disabled the audit records will just accumulate on the message queue and as long as disk space is available you won't loose anything - (RAIDing etc).

Auditing user\system actions is always business requirement - we don't track what user\system do for our benefit so why do it as an after thought...

Oh and you can probably guess I hate triggers on tables too ;)



Awkward Coder

Read More

Repository pattern - my preferred implementation...

Okay it's nothing new and not even original but I wouldn't to get down my currently preferred implementation of the repository pattern. I suppose this was prompted by a blog by Jimmy Bogard and Oren's statement a couple of months ago the repository pattern may be near then end of it's life.

I still think in the .Net world they have great relevance as most .Net devs can't organise code for toffee and when you try and introduce layering into an application the use of an explicit repository layer is the first layer they seem to understand.

So here is my current repository flavour - strawberry with a twist of lemon...

 public sealed class Repository<T1, T2> : IRepository<T1, T2> where T1 : IEntity<T2>
    {
        private readonly ISession _session;
        private readonly string _traceType;

        public Repository(IProvideSessions sessionFactory)
        {
            _traceType = string.Format("Repository<{0}, {1}>: ", typeof(T1).Name, typeof(T2).Name);
            _session = sessionFactory.GetSession();
        }

        public T1 Get(T2 id)
        {
            Trace.WriteLine(string.Format("{0} Get - '{1}'.", _traceType, id));
            return _session.Get<T1>(id);
        }

        public void Save(T1 instance)
        {
            Trace.WriteLine(string.Format("{0} Save - '{1}'.", _traceType, instance.Id));
            _session.Save(instance);
        }

        public void Delete(T1 instance)
        {
            Trace.WriteLine(string.Format("{0} Delete - '{1}'.", _traceType, instance.Id));
            _session.Delete(instance);
        }

        public T1 FindOne(IFindable findable)
        {
            Trace.WriteLine(string.Format("{0} FindOne, - '{1}'.", _traceType, findable.GetType().Name));
            var criteria = findable.BuildCriteria();
            return criteria.UniqueResult<T1>();
        }

        public IList<T1> FindAll(IFindable findable)
        {
            Trace.WriteLine(string.Format("{0} FindAll, - '{1}'.", _traceType, findable.GetType().Name));
            var criteria = findable.BuildCriteria();
            return criteria.List<T1>();
        }
    }

One of the first things to notice is the use of two generic types T1 & T2 - I'm not great at naming generic parameters so they never got better names. Hopefully it's obvious but T1 is the domain entity and T2 represents the 'Id' column for the entity (All DDD entities have Id's).

The other important feature is the 'FindOne' & 'FindAll' methods they take an implementation of the interface IFindable which performs the magic. Now this is where the generic repository starts to have a 'leaky abstraction' and this happens to be exposing nHibernate's ICriteria interface vai the IFindable interface. The implementation of the IFindable is responible for the creation of the NH criteria and returns this when requested, this is then executed by the repository and volia the results are returned.

So my current repository pattern is designed to be used with NH, but if a client dictates I can't use NH then I will modify the IFindable interface accordingly or I will terminate the contract depending on how I'm feeling :)

 public interface IFindable    {        ICriteria BuildCriteria();    }

An example of this could the a Findable class that returns an NH criteria that will return bank customers with a balance greater than million - Millionaires!

public sealed class FindValuedCustomers : IFindable
    {
        private readonly ISession _session;

        public FindValuedCustomers(IProvideSessions sessionFactory)
        {
            _session = sessionFactory.GetSession();
        }

        public ICriteria BuildCriteria()
        {
            return _session.CreateCriteria(typeof(Account)).Add(Property.ForName("CurrentBalance").Gt(1000000));
        }
    }

Now I can see how Oren goes from this to the idea of just using NH Session anywhere in the code you previously used a Repository but I do think there is still some requirement to provide a layer & abstraction for testing purposes.

One other thing to note, I do believe the Repository pattern has valid uses outside of DDD, as Eric has stated most of the common patterns in DDD existed before the book.



Awkward Coder

Read More

Auditing with nHibernate...

Long time since I've posted anything but I came across an interesting problem the other day whilst I was working - 'How can I audit changes to specific entities when using nHibernate?'

There are several implementation out there already (see Oren's & others posts) but of ones I've seen they are to low level for my liking - they push the auditing of changes into the NH infrastructure away from the Service implementing the business behaviour. I want my service to control and define what is audited I don't want everything audited in the same manner. Auditing for me is the pushing out of events that have affected entities persisted in an OLTP database to OLAP database ideally in an asynchronous manner via some queuing mechanism (MSMQ).

So how do you get events from NH?

Now if you want to observe changes to entities in NH you have to register you're interest by passing an implementation of an IXXXListener interface to the NH configuration when create the SessionFactory, this is the classic implementation of the observer pattern and I guess it's like this because this is a straight port from java - it doesn't follow the .Net approach of EventHandlers & Events, I'm liking this approach as it gives exposure to a different implementation.

What did interest me about this implementation was that as user of the NH Session I can't register with the Session my interest in observing changes to the entities. I have to do this with the SessionFactory and therefore I'm getting notified of ALL events to ALL entities whilst this SessionFactory is alive.

So you can register your interest by implementing a class and passing this to the NH configuration - I've tried to keep it simple by register for events that tell me when CRUD operations have been completed on entities, this is done by implementing the following NH interfaces:

IPostInsertEventListener,
IPostLoadEventListener,
IPostUpdateEventListener,
IPostDeleteEventListener.

I also created an interface called IObserveNHibernate that fires traditional .Net style events when an NH event has been observed.

I've left out all the XXXEventArgs classes from the post for brevity - I hope you can figure out the structure!

public interface IObserveSession<T> : IDisposable where T : IEntity
{
event EventHandler<SessionEventArgs<T>> EntityLoaded;
event EventHandler<SessionEventArgs<T>> EntityCreated;
event EventHandler<SessionEventArgs<T>> EntityUpdated;
event EventHandler<SessionEventArgs<T>> EntityDeleted;
}

So the class looks like:

public sealed class NHibernateObserver : IObserveNHibernate,
IPostInsertEventListener,
IPostLoadEventListener,
IPostUpdateEventListener,
IPostDeleteEventListener
{
public event EventHandler<NHibernateEventArgs> EntityLoaded = delegate { };
public event EventHandler<NHibernateEventArgs> EntityCreated = delegate { };
public event EventHandler<NHibernateEventArgs> EntityUpdated = delegate { };
public event EventHandler<NHibernateEventArgs> EntityDeleted = delegate { };

public void OnPostDelete(PostDeleteEvent @event)
{
EntityDeleted(this, new NHibernateEventArgs(@event.Entity));
}
public void OnPostInsert(PostInsertEvent @event)
{
EntityCreated(this, new NHibernateEventArgs(@event.Entity));
}
public void OnPostLoad(PostLoadEvent @event)
{
EntityLoaded(this, new NHibernateEventArgs(@event.Entity));
}
public void OnPostUpdate(PostUpdateEvent @event)
{
EntityUpdated(this, new NHibernateEventArgs(@event.Entity));
}
}

And this class is then used when creating the SessionFactory for NH. Now currently I wrap the creation of the NH SessionFactory into a custom SessionFactory - this class usually exists as a singleton in the host process and lifetime is managed by the IoC container (it's marked as a singleton).

This SessionFactory is backed by an interface, that defines 2 methods - one for access to the Session & the other for accessing an implementation of SessionObserver<T> exposed as an IObserveSession<T> interface, where the generic T represents the entity type I'm interested in observing.

So the interface looks like:

public interface IObserveSession<T> : IDisposable where T : IEntity
{
event EventHandler<SessionEventArgs<T>> EntityLoaded;
event EventHandler<SessionEventArgs<T>> EntityCreated;
event EventHandler<SessionEventArgs<T>> EntityUpdated;
event EventHandler<SessionEventArgs<T>> EntityDeleted;
}

The interface implements the Dispose pattern so the un-hooking of events automatically happens when you've finished observing NH events. The implementation of the interface is show below:

public sealed class SessionObserver<T> : IObserveSession<T> where T : IEntity
{
public event EventHandler<SessionEventArgs<T>> EntityLoaded = delegate {};
public event EventHandler<SessionEventArgs<T>> EntityCreated = delegate {};
public event EventHandler<SessionEventArgs<T>> EntityUpdated = delegate {};
public event EventHandler<SessionEventArgs<T>> EntityDeleted = delegate {};

private IObserveNHibernate _observer;

public SessionObserver(IObserveNHibernate observer)
{
_observer = observer;
_observer.EntityLoaded += (HandleEntityLoaded);
_observer.EntityCreated += (HandleEntityCreated);
_observer.EntityUpdated += (HandleEntityUpdated);
_observer.EntityDeleted += (HandleEntityDeleted);
}

public void Dispose()
{
_observer.EntityLoaded -= HandleEntityLoaded;
_observer.EntityCreated -= HandleEntityCreated;
_observer.EntityUpdated -= HandleEntityUpdated;
_observer.EntityDeleted -= HandleEntityDeleted;

_observer = null;
EntityCreated = null;
EntityUpdated = null;
EntityDeleted = null;
}

private void HandleEntityDeleted(object sender, NHibernateEventArgs args)
{
if (args.Entity is T)
EntityDeleted(this, new SessionEventArgs<T>((T)args.Entity));
}
private void HandleEntityUpdated(object sender, NHibernateEventArgs args)
{
if (args.Entity is T)
EntityUpdated(this, new SessionEventArgs<T>((T)args.Entity));
}
private void HandleEntityCreated(object sender, NHibernateEventArgs args)
{
if (args.Entity is T)
EntityCreated(this, new SessionEventArgs<T>((T)args.Entity));
}
private void HandleEntityLoaded(object sender, NHibernateEventArgs args)
{
if (args.Entity is T)
EntityLoaded(this, new SessionEventArgs<T>((T)args.Entity));
}
}

So I have a custom SessionFactory that looks something like the following - pretty standard NH Session semantics and the new method SessionObserverT - this creates an instance of the SessionObserver<T> per request.

SessionFactory interface:

public interface IProvideSessions
    {
        ISession GetSession();
        IObserveSession<T> SessionObserver<T>() where T : IEntity;
    }

SessionFactory class:

public sealed class SessionFactory : IProvideSessions
    {
        private readonly ISessionFactory _sessionFactory;
        private readonly NHibernateObserver _nHibernateObserver;

        public SessionFactory(string connectionString)
        {
            _nHibernateObserver = new NHibernateObserver();

            var cfg = new Configuration();
            cfg.EventListeners.PostLoadEventListeners = new IPostLoadEventListener[] { _nHibernateObserver };
            cfg.EventListeners.PostInsertEventListeners = new IPostInsertEventListener[] { _nHibernateObserver };
            cfg.EventListeners.PostUpdateEventListeners = new IPostUpdateEventListener[] { _nHibernateObserver };
            cfg.EventListeners.PostDeleteEventListeners = new IPostDeleteEventListener[] { _nHibernateObserver };
          
            _sessionFactory = Fluently.Configure().ExposeConfiguration(c => cfg.Configure())
                .Database(MsSqlConfiguration.MsSql2005.ConnectionString(connectionString).ShowSql())
                .Mappings(m => m.FluentMappings.AddFromAssemblyOf<IEntity>())
                .BuildSessionFactory();
        }

        public ISession GetSession()
        {
            return _sessionFactory.GetCurrentSession() ?? _sessionFactory.OpenSession();
        }

        public IObserveSession<T> SessionObserver<T>() where T : IEntity
        {
            return new SessionObserver<T>(_nHibernateObserver);
        }
    }

So an example of how I would use this is show below, it's a little contrived and not tested but I hope you get the idea:

public class CashService
    {
        private readonly SessionFactory _sessionFactory = new SessionFactory("SOME CONNECTION STRING");

        public void Debit(string accountNumber, decimal amount)
        {
            using(var session = _sessionFactory.GetSession())
            using(var trans = session.BeginTransaction())
            using(var sessionObserver = _sessionFactory.SessionObserver<Transaction>())
            {
                sessionObserver.EntityCreated += ((sender, args) => AuditTransaction(args));

                var account = session.Get<Account>(accountNumber);
              
                session.Save(new Transaction(account, amount));

                trans.Commit();
            }
        }

        private void AuditTransaction(SessionEventArgs<Transaction> args)
        {
            // Write transaction event to audit queue...
            // if fails the throw exception...
        }
    }

Now I've not tested this fully and I'm not sure of the viablity of this option or whether I like the end usage - I suppose I could wrap the NH Session behind a custom Session class that exposes the events directly. But it's a start at thinking how I'm going to achieve the auditing required.


Wow that was longer thanexpected ;)

Anyway till next time...


Awkward

Read More