Patterns , Request and Response – Why

Recently i was asked by members of my team why we used the Request and Response Messaging pattern, it lead to a interesting conversation form which we resolved number of high level points, i thought i might share them here.

When dealing with 2 systems with defined edges such as a group of services which perhaps form a SOA [Service Orientated Architecture] , it is quite often advantageous to implement strict communication standards.

In the physical world when we enter into a conversation with another person it is considered good manners to wait for a response when we have made a statement or asked a question in short we have spoken and set by convention a expectation that we will receive some form of response.

We often that this is form of communication collaboration is more constructive than constantly communicating in such a fashion as to demand things form our audience as if they are in fact slaves to our every wish as opposed to collaborators in a well mannered interchange.

These two social interchange patterns can be summarised in the following definitions:

# Ask don’t tell
# Tell don’t ask

We see both these communication constructs in the software world.

Tell Don’t Ask
Traditionally in classic code we consume objects and call there methods directly passing to them parameters. The expectation with this style of programming is that the object will just do what we say when we say it as a consumer.
The object becomes a slave to the consuming code.

Ask Don’t Tell
There is a alternative to the demanding style of code we demonstrated with the ‘Tell Don’t Ask’ methodology. We can make a active choose to communicate with other objects in a way which treats the objects with good manners.

We can request the object to perform an operation for us and then wait for a well mannered response form the object.

When work in this way we can establish a convention that say in simple dialect.

‘When i send a request to an object, that object is guaranteed to make a response even if the object has nothing to say back to me other than it has completed my request and the status of that request at the point it was completed.’

Why would we want to do this?
By engaging in a collaborative relationship within the domain space with other objects we achieve a number of thing.

# We protect the object interface and give the object room to grow and evolve as all it is expecting is a Request and all we are expecting form it is a Response.

# We make the object a collaborator in a domain relationship and therefore we honour its right to control its own state and to hide form us its implementation.

# We guarantee a response from the object by convention , therefore we are free to engage in other conversations while listening for our object to come back and talk to us.

#We can ask the object to enrol in a group chat were perhaps we have multiple collaborators who are responsible each other and to our initial object for the overall context of the conversation. We can even become the orchestrater of the group and direct the flow of the conversation to a active a collective result.

#We are implementing a true black box SOC [ Separation of Concerns] paradigm at a object level with this pattern.

#Messages can be made durable and persisted if need be

#Messages can take part in a retry type pattern

#We are modelling the real world with this relationship

I hope this post gives food for thought and provokes deeper conversations into collaborative code relationships as opposed to slave based enforced patterns.

London Azure User Group

Link: http://www.lwaug.net/

Organisers: Andy Cross andy@bareweb.eu , Richard Conway richard@azurecoder.com

Other Blogs: http://blogs.msdn.com/b/plankytronixx/archive/2011/12/09/london-windows-azure-user-group.aspx

Slides and media:

http://lwaugbe.blob.core.windows.net/talks/Service%20Management%20Dec%2011.pptx

http://lwaugbe.blob.core.windows.net/talks/Fluent%20Diagnostics%20Dec%2011.pptx

Well i attended the London Azure User Group last Tuesday the room was filled with heavy weights and people just interested in finding out more about Azure. It turned out to be a fantastically interactive evening with talks on Diagnostics delivered by Andy Cross and a amazing talk on the Rest manipulation of the Management API by Richard Conway.

We were treated to pizza and beer and we had a some excellent opportunities to network within the group.

I think its very obvious this is the Azure presence the UK has been missing for a long time it is now up to the community to gather round this event and support Andy and Richard and really help to drive this forward.

Andy and Richard have fantastic ideas to extend this to include Code breakfasts and other engaging activities to try to sponsor Azure adoption within the community, i really feel that this is going to be  a huge success and my thanks go out to the guys behind it.

Elizabeth Rebecca Martin

Azure Consultant and Agile Evangelist

Agile or WAgile – Discussion : Agile Part 1

Introduction

This post represents the first half of a pair of posts which will attempt to lay out some fundamental techniques which i have found helpful in delivering projects that are on time and fit for purpose, in this first post i would like to examine the difference between Agile and what is commonly referred to as WAgile. In the second post i would like to talk about requirement gathering using stories and prototypal design.

At the heart of Agile techniques is a principal of known as people over process, let us for a moment focus on one of the intrinsic component’s of this principal – ‘Collaboration’ – when we collaborate with each other we get more done, this is a historical fact proven in many aspects of life including great engineering achievements from the channel tunnel through to huge military campaigns.

When we collaborate in the Agile setting we need to enter a mind set which can be quite alien to traditional project management, due to the blame avoidance culture we typically find in hi $$ projects we tend to find abstraction and deflection in use rather then clarity and inclusion, this is generally driven by the fear of ‘Showing ones dirty washing , as it were’.

 

For projects to succeed under the Agile banner we must become a team composed from a number of organisations working to achieve an end goal ‘ producing a fantastic fit for purpose deliverable’ for this to be really achieved the boundaries between roles within the project ecosystem and their associated rights and privileges must become so blurred that typically in time they become background noise and new project centric roles spring into place which are flexible and distinct from the persons employing organisation. In short the team becomes a cooperative matrix of team centric players within the project ecosystem, rather than employees of one of the contributing companies.

 

If you do not feel it is possible to facilitate this type of relationship with the client and the other parties involved,  other techniques might come into play such as the use of a ‘Internal Customer’ who can be the bridge between the client and the team. However this is not optimal and many projects find themselves gradually slipping into a waterfall style methodology consequently blaming Agile for a failure when in fact they were not practising agile but a hybrid methodology that is classically referred as WAgile process – see the diagram below for how this might look.

Diagram : WAgile in action

Within the Agile space there are 2 primary approaches to Agile Development

• Scrum
• eXtreme Programming

It could be argued that there are other front runners such as DSDM and then we must also consider the LEAN methodology sets as well, the distinction between different flavours of Iterative development techniques  is becoming increasingly more blurred as this group of methodologies gather a growing number of converts each contributing their distinctive flavour to the community.

However ‘What is Agile?’ is beyond the material I wish to discuss in this post , so let us instead accept that there are a number of buckets of techniques which all at their heart have the principals of the Agile Manifesto (http://agilemanifesto.org/) the guiding principles of which I quote for convenience below:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

As you can imagine with this amount of scope for variation an agile environment can take many shapes; so instead of trying to cover each possible variation, I will provide below a diagram which illustrates some of the common factors that can be found in a Agile environment:

The biggest differentiator between the WAgile illustration  and the Agile illustration is the communication dynamics between stakeholders, the team, we also see a distinct difference in the team value statements.

Commentary

The WAgile environment uses artefacts such as project plans , long meetings , vast swathes of documentation to try to provide an accountable environment were every thing is locked down to the following factors:

• Who takes responsibility for doing it
• How long will it take
• Who holds liability if it all goes wrong
• Who’s going to pay for it
• What is the immediate profit margin on the work
• Do we project that this will take us over budget
• The above quite often translates into stress / toxic pressure expressed as can we push elements of the team harder to get this done faster

While there are important issues illustrated in these points, trying to mitigate them creates a huge risk to project completion. Classically the techniques used in a Waterfall / WAgile environment to constantly answer and document the above points leads to a lack of freedom and flexibility  and a total inability to do what is needed to just get it done at the coal face. It should be noted that we also generate a environment of fear where people and companies are scared to take risks, once there opinions or improve quality.

With the on-going need to document everything and to have a paper trails for all aspects of the project, we find we end up creating roles within the team who’s sole job is to protect the company or shift liability onto other individuals, partners or companies. Thus it can easily be seen that in the attempts to lock down the Cost, Liability, exacting time frames and Risk – we find that making even the smallest movement in the project space has huge cost and requires layers of sign off and discussion this effectively knee caps the teams ability to flex to changing conditions and to innovate when the opportunity presents itself. All of the above leads to teams creating yet more documentation in attempts to fully lock down requirements in advance including some of the following documents which quite often make for miniature novels they are so great in length.

• BRS [Business Requirement Specifications]
• Static Wireframes
• Business flow diagrams
• Huge Class diagrams that document architecture which might not be needed
• Ultra high quality creative tied down to the exact pixel
• In depth NFR’s [None Functional Requirements]
• Massive Risk logs which at times almost go as far as to include acts of god

Worst still for the team is the fact that most of the above form some sort of reference material within the overarching contractual agreement which generally means making changes to them takes a huge amount of time, effort and stress. One of the other factors to add into the mix is that quite often the wrong people have written these documents or the right people have written them under huge time pressures – the end result is tends to be more a set of hand-cuffs as opposed to empowerment.

The Agile environment drives for the concept of people over process, as such the number of inflexible paper artefacts are reduced, meetings tend to take the format of time boxed [normally 15 mins or less] whole team meetings these are quite often known as touch point meetings. In terms of risk most teams tend to practise ‘Don’t put off for tomorrow what you can deal with today‘ This can take the form of writing technical debt cards and having a regular technical debt review cycle or more preferable dealing with problems as they pop up.

The classic Agile environment will also try to practise philosophies like ‘Better to ask forgiveness , than to ask permission’ in general the the Agile player is a brave soul who just gets in there and gets it done, he can afford to work like this because of the tight communication across the team elements regardless of discipline he/she is given further confidence by knowing that team shares:

• Shared Code Ownership
• Shared Feature Ownership
• Shared Liability
• Shared responsibility for getting right
• The team practises open communication and transparency across all discipline
• Fear is not part of the team culture
• The team makes joint decisions in transparent meeting and the concept of ‘Command and Control’ has no place in the Agile teams culture
• Personal Ego is left at the door
• Team Ego and identity of team self is implicit to an agile team
• One is none , two is one [Pair Working – across planning, programming and all other applicable activities within a agile team]

One of the techniques an Agile team frequently borrows from Lean methodology is the concept of a [Red flag], this concept says that no matter a persons position inside an Agile team that person can raise a red flag , physically , by Email, by calling a meeting when they believe things are going to come off the rails and the effect of this action is everyone no matter their position stops and there is a conversation to put the situation right before the team continues.

The one main driving force behind an Agile team is not who’s fault it is , a true agile team even one split across organisations operates on a Zero blame culture because it operates on a understanding that everyone is doing there absolute best to achieve one single aim – Continually deliver high quality , demonstrable software that is 100% fit for purpose and it is this one aim that members of an Agile team no matter the company they represent or the horizontal stripe to which they belong in the ecosystem strive for, and this is one of the biggest differences between WAgile / waterfall and true Agile, true agile concerns itself totally with delivery not politics.

I as the author of this post can understand that the above statement may seem naive in the high dollar industry in which most projects live, but I would challenge back to you and ask you one simple question – would you bet all your process , artefacts and safeguards against project success – because an empowered agile team given an even playing field with a bought in client will be successful and will deliver with low bug counts and high feature saturation.

Interface first development and Mocking [Overview]

30 Second Overview

Although this technique really falls within the ‘Emergent Design Umbrella’ it would be remiss of me to not to write a quick overview.

This technique introduces two visualizing concepts to the reader:

• Coding shallow and wide
• Implementing deep

Ok so what does all that mean , well in simple terms your aim is to code in multiple passes the first pass you implement the behaviour to satisfy your BDD test by hammering out interfaces and you mock everything do not even allow your mind to wonder to the how do i implement X instead just trust that it will become clear as you proceed.

So in the first pass everything or almost everything is a mock and you will be passing values into one mock and pulling them out of another when you stand back and look at that first pass your first reaction will be that’s pointless, mine certainly was the first time i did.

But if you have now coded shallow.

So next start pushing down towards your deep end point perhaps a mocked repository or some such. So next you might make the Adapter concrete and start to implement a service call perhaps via a channel factory. This will of course lead you to implement the service and because we are best practise team you will be injecting into it via its constructor (DI/IOC) its repository which is still mocked.

So you will be driven in the setup code for your test to hammer out the host and perhaps a Unity (or other DI) service behaviour/host/ binding then you will rerun your test ad you will find that now you have coded deep and implemented the behaviour you prototyped in the first pass. So you move on till you get to the your test end point which might be a in memory database or a mocked repository or something else that suits your domain pattern.

The golden rule with this is ‘ Implement only when driven there, delay implementation of an object as long as practical and sensible’.

Emergent Design [Overview]

30 Second Overview.

This technique says that ‘As our requirements are implemented so our underlying design will emerge’ although it is likely that we will have made some over arching decisions such as the client application will be Silverlight we will use RIA services and so on.

In simple terms the design decisions are delayed until we are driven to make them by following our Tests and the artefacts produced by those tests. So there is no upfront design phase and no need for a architect or technical lead as all members of the team are equally empowered and responsible for architectural decisions as they get to the point a decision can no longer be delayed.

Emergent Design says also that all developers in the team are equally empowered and there is no need for a tech lead or over arching solution architect / design authority although you may still need a gate keeper for the domain / domain architect to enforce company wide design options and integration between systems.

Using this principal, communication is imperative across the team , headphones should not be warn in this type of environment information saturation via Osmosis is beneficial as is courage to speak if you don’t agree with something you over hear.

It is also a classic aspect of this type of team that documentation will live in card task lists and although at a seconds notice any team member will be able to draw for you on a white board the solution architecture no architecture diagrams will be produced and generally Visio is a dirty word as each member would expect his colleagues to be able to run a white board session to explain the current architecture therefore making diagrams a outdated slow moving asset that has no place in a emergent environment.

Some of the advantages

• Fast iterative cycles
• Flexibility within the architecture to change as the requirement dictates ( flock of swallows principal )
• Spread of architecture knowledge across the team
• High quality development , is achieved by architectural chooses under continual review by all developers
• Highly empowered and motivated team
• Distributed code and architecture ownership
• Encourages small checkins and atomic coding practises
• Highlights weaknesses in the team quickly and encourages individual and team level skill patching
• Iteration 0 /1 is a productive iteration rather than spending it debating architecture
• With this style of team everything is immediate you see it , you deal with it very little technical debt is built up as the team will feel uncomfortable with passing by a architectural issue and not solving it immediately, this could probably belong in both challenges and advantages though i see it as the latter speaking from a personal stand point.
• This method tends to lead to a lot of code reuse and due tot he high rate of refactor that is performed with this method the code tends to be of a very high quality with very little fat and subsequent lower maintenance foot print.
• Because the code is under continual review by the whole team plus the reliance on B/TDD techniques the bug count at point of release is normally very very low.

Some of the challenges

• Recruitment becomes very difficult as all the people on the team must pass a minimum bar there is no room for juniors on teams practising this principal, or passengers. ( Principal the team is in this case as strong as its weakest member and as fast as its slowest pair )
• High code churn as the architectural changes are implemented on the fly across the whole solution not just the focus of that particular card , a architectural refactoring must be cross cutting across preceding code as well as the current card scope.
• Team must communicate verbally , its imperative that the person proposing an architectural change communicates that change to the rest of the team and they respond in a speedy and honest fashion – fast white board sessions are ideal for this ( hint: time box), there is no place to hide in this sort of team.
• Velocity can become uneven as people make large refactors, reducing there perceived productivity.
• This technique does not work well in distributed teams, with out implementing a lot of overhead.
• It is imperative that there is a understanding of you touched it you own it , in other words just because you didn’t write it , doesn’t mean you can see something you disagree with and pass it by and mentally think ‘ oh well its not my code’.
• If used with teams that lack maturity or teams that have an element within them that has not brought into this technique , this technique can cause a lot of animosity.
• It is imperative that this technique is practised with full test coverage , a solid CI (Continuous Integration) it is generally a rule with teams that practise this approach that the code base is constantly deliverable, demoable and a candidate for shipping should it be required, any high risk development is done in a branch and then integrated and generally is spik’ed out first.
• This technique works best in self organising teams and works badly in command and control style structures.

BDD [Overview]

30 Second Overview.

One of the main disciplines the teams i work with is Behaviour Driven Development this approach to software design was introduced to the community by Dan North a number of years ago and although it has not gained the following its sister discipline of TDD (Test Driven Development) has gained, those that practise BDD tend to produce a far more accurate representation of the Business Analysts vision and thus the customers dream.

Within a BDD Test / Spec we aim to use common English language sentence to describe the functionality that we need to be produced our scope is a business stripe though the technical layers rather than a method or object as in TDD.

Brief Presentation on some of the BDD frameworks in common use: https://www.box.net/shared/2tfmm2ubgo

Some of the advantages

• Requirements are the driving force behind the tests , which in turn drives the code
• The technique trims away code waste
• The technique creates a pit of success for the developer
• The technique encourages other good practises such as contract first development and emergent design principals.
• Helps developers understand what ‘Done’ really is for the story

Some of the challenges

• The technique requires a lot of discipline across the team
• The technique takes away some of the freedom from developers
• The technique doesn’t work in environments where P & P , SOLID and best practises are not followed.
• The technique required a ‘BA’ role to be performed within the team
• The BA must be very explicit in there requirements and child acceptance criteria, also it is helpful if they supply wireframes and such like to augment the requirement statements

Making the Magic happen.

Introduction

 

Full code and dependencies here : https://www.box.net/shared/7yp3zthf8i

 

In this series of blog posts i would like to illustrate a number of techniques myself and the teams i work with regularly use to produce high quality software that delivers to the end user requirements.

The teams i work with and put together tend to come from the agile side of the software development camp. I will blog in coming weeks about requirement gathering and interviewing clients conducting workshops and other more ‘business’ focused techniques but i would like to start of with some development focused posts.

In the next 2 posts we will be using:

• BDD ( Behaviour Driven Development ) [ Click for Side bar on the subject ]
• Emergent Design [ Click for Side bar on the subject ]
• Interface first development and Mocking [ Click for Side bar on the subject ]

Example

Enough talk , more action …

Below we have a simple example of a story which has 2 acceptance criteria defined in the remainder of this post we will cover the shallow dive. In the second post we will then dive deeper implementing the service layer and the persistence layer.

Tools

A quick note on tools we are using visual studio 2010 and Resharper , trying to do this sort of work with out Resharper is like trying to run a marathon with a broken leg you can do it but it will hurt lots and lots. This is so true that when i do contract work i have my own personal licence just in case the client doesn’t have Resharper, Generally by the time the contract has come to an end the whole team is using Resharper, it is that good a tool.

Story :

As a HR Administrator

When a New Employee starts work

Then I Expect to be able to register there details on the HR system

Acceptance Criteria :

1. As a HR Administrator

When i create a new record for a Employee

Then I Expect  to enter the following information

• FullName
• Date of birth
• Address

2. As a HR Administrator

When have entered all the employees details

Then I want to press save

And I Expect to see the employee on the employee list view

Lets get straight to some code

As usual we start with a class library with no framework or references we will be building this example in a purely emergent fashion.

 

Ok we have introduced some intent into the test with the name of the class but let us remember it is up for grabs to rename later , the name we have currently chosen will suffice for now and will get us going , as we explore the requirements and intent. (Tenet: Its ok to be wrong, as long as what you decide is good enough to allow you to move forward).

 

Next we add a operation to represent the intent of our test and decorate it with the Test attribute remembering to add the TestFixture Attribute to the class declaration. We then need to add our testing assemblies i have chosen to use NUnit and some of the NSpec extensions that have been rolled into the NBehave Project. (Tenet: You don’t need it till you are driven to it , wear blinkers, ignore your pre knowledge.)

So now we start to get into the implementation itself so we next write the story adding reference to the StoryQ dll, Resharper helpfully highlights the unimplemented steps in red, so lets Alt-Enter on each and resolve it.

so using Resharper and IntiliJ Mappings we can click on each red unimplemented method and choose ‘create method’ option 2.

We then have a method stub for each step in the story and we are now in a position were by clicking on Resharper ‘yellow and green test icon we can run the test and get our first set of output.

So having run the test we can see that all the steps are pending so now we need to move on and implement the steps, the framework knows that they are pending because of the ‘NotImplementedException’ which is thrown, you will recall Resharper but those in each method by default for us.

 

The next step is to conceptualize the UI , so lets set the ‘EmployeeName’ property on the ‘conceptualized EmployeeCreator’ form.

So using Alt-Enter on Resharper we add a field and tell the system we will be using a Mock of type ‘IEmployeeCreator’ so we now need to get our mocking library my personal favourite id Moq.

With the Moq reference in place and our interface created were ready to implement the property on the interface, and verify it gets set on the mock, making its behaviour explicit within the universe of the test.

Next we set up the property on the Mocked View so we can set it, following the intent of the step. (Hint: Calling ‘Object’ on a Mock(Moq) returns to you the real object and then you can call the properties and operations as if it was a concrete object which in turn will obey your setup directives.

Next we run our test and it complains that the interface ‘IEmployeeCreator’ is not public so we fix that and re-run.

Back in the IDE we get driven to code, in the next step we enter the employees address now in reality this would probably be broken down into country , state, zip code and so on for the sake of this contrived example we will keep it as a simple string as opposed to pushing through to a address object. Note on this is that even in a production environment we might find ourselves well served just to implement a simple string and then once we have the test passing refactor this to a Address object.

 

We can see above that Resharper is telling us that the address property is not implemented so again we alt-enter on the method name and Resharper implements a property for us.

Again we follow our work flow and run our tests , then we implement the next step, the Date Of Birth which again drives out another property leaving us with:

The piece that i have delayed showing you as i did not want to distract attention from the work flow, is that Moq has a really useful piece of functionality for stubbing properties. Now we have more than 1 property on the Mock of the IEmplyeeCreator interface we will take advantage of this functionality, to do this In our set up method i have now add the following line of code:

This effectively creates automatic properties on your Moq object for each property expressed on your interface. This is very useful when we don’t want to verify a property or express some expectation on the event that property is set or get.You can think of it in terms of short hand for a Stub.

So where are we, and what has our story have produced so far?

We have the concept of a view double by mocking the IEmplyeeCreator  Interface , we will use this to define the UI implementation object a little later. We have on this interface defined a number of data items that we need the user to set, we have ‘for now’ used a mock all properties method on the Mock to do this as we are not concerned about these properties at this point.

The Last mile

Lets move to the next step in the story and a re-read it and it is talking about a save button i decide im uncomfortable with that because it is not abstracted enough and is implying implementation which as ‘Story Author’ I don’t want to really think about, So i click on the operation name and press ‘F2’ and Resharper opens its rename dialog.

I rename the step like so :

So having changed the semantics i move on to the implementation,  there are a number of things i can do here but as i like to keep my implemented UI as thin as possible i decide to raise an event to trigger the save operation, this also allows me to abstract if i so desire later the save operation to a outside collaborator such as Model / ViewModel or manager/ controller.

Ok so this bit is a bit of a big step but its were we finally start to see a connectivity point into the wider system be introduced.

First of all as discussed above we raise a RequestSave Event and at this stage i decide there isn’t a good reason to do anything other than cast the form to a interface which represents the data only and pass it out as a Argument in the eventArgs, this may change later but remember were wearing blinkers and doing only what we must to implement the behaviour.

We set up an event handler on our Mock / stub (View double) as we have no need at this stage for an orchestrator like a controller or presenter or such , but again we may do later.

As you can see above we have finally introduced our adapter , and although this is a long post in a production environment this is about 10 minutes worth of coding effort, for a pair with knowledge of the technique.

Ok so now we must mock our adapter and we must bring in our data interface and build our EventArgs class.

 

With these pieces in place we can see that when we run our story we are nicely taken to the the final step.

To Recap

• We have represented a Behaviour in a story
• We have created a View Double
• We have created the concept of the user data
• We have created a action and a interaction between to members of the code domain the view and the adapter which is the entry point to our larger system
• We have one step out standing before we can get a green passing bar and start driving deeper into the system via the adapter.

The final Step in our shallow dive

 

We now set up our expectation in our final step again our entry point is the form double and in this case we are using the NBehave Extensions. Note this is a slightly modified copy of the extensions that i worked on with Agile Workshops Ronnie Barker, they can be downloaded from :http://blushpackages.com/downloads/Nbehave_extended_with_source.zip or you can use the production NBehave extension form the NBehave Org.

 

This leads use to implement another event on the form double.

With this full collaborative exchange with the Adapter , i now feel driven to implement this object as such our next step is to create a concrete adapter. We let Resharper do the heavy work by adding the interface to the implementation list of the new class, and pressing alt-enter on the red squiggly line.

Once this is implemented we can go back and remove our service adapter mocks and use the concrete class. Principal Mocks are not always for life  , quite often they allow us to move forward till our design has emerged from our intent enough to demand a concrete implementation of the object.

This drives us to a decision point in our test intent originally we had this step which we had satisfied with a step declaration like so:

So in simple terms we wanted to know when the record had been saved in the service , so after going back to the story [ And potentially the Story Author / BA ]it is now plain to us that actually we don’t care about this step , what we care about is that when we ask for the list of employees we want to see the employee details in it. So we can safely remove this step. Principal don’t panic to much about your understanding of the story at the start the understanding will deepen and emerge as you move forward with the implementation of the story.

So as we can see above we now have a concrete Service adapter which as you will see in a moment leads me to implement a concrete employee object which is also visible in the above screen shot.

 

So if we re run our tests having implemented the concrete adapter we get to our NotImplmentedException as you can see our behaviour is driving us each step of the way.

 

So lets implement these method and get back to a clean state.

 

The next thing we do we raise the RequestEmployeeList event on our View Double.

Next we implement the handler for the RequestEmployeeList event and we call the GetEmployeeList from the now Concrete Service adapter.

This then drives us after running the tests to implement an internal storage in the adapter like so :

This then leads us to run our tests and we get yes a Green Bar thus we have completed our shallow dive between the form double and the client side end point the adapter.

I fully appreciate this is a long post but as stated above in a production environment with Resharper and keyboard/short cut skills this is no more than 10 – 15 minutes of work.

With out these skills and tools this is a lot longer normally measured in hours.

I hope this has been helpful. Next time we will look at implementing the View Double as a winform application using Unity IOC.

Full code and dependencies here : https://www.box.net/shared/7yp3zthf8i