Yes I am mocking you

Agile development practices may seem easier for small, isolated teams, but what happens in the real world when applications go across teams and dependencies to rear their ugly heads?  The answer I hear too often is ‘adjust in your planning sessions so that the dependencies go away.’  That’s not a real, complete solution to me.  Here is why – that answer makes sense if we are creating an application and we have two stories – Add item to shopping cart and Remove item from shopping cart for example.  In this case it’s logical to plan accordingly.  We wouldn’t want to release the product without being able to add items, and this functionality seems in control by the team.

 

What about this more common example though – a front end team develops an application that depends on data from a data team.  On top of that, not only does the front end team depend on the data team, but so do 3 other teams, all with different priorities and needs.  And since it is the real world, we have a deadline to hit – the application needs to launch in 6 weeks and the data team won’t be able to finalize the data for the front end team for 4 weeks.  It doesn’t make sense for the front end team to not work, especially if the amount of time they need is greater than the remaining two weeks.  What do you do?

 

There isn’t a simple answer to this.  You don’t get to wave the magic Agile wand and voila – problems solved.  Yes, ‘push the date’ may be the easy out, but that isn’t always possible or even recommendable.  TDD leveraging Mocks won’t solve this problem, but it will allow teams to continue working, deferring those dependencies to as late in the game as responsible.

 

What are mocks? A mock is a fake representation of an object (in this case an object that might not exist or be implemented yet) that developers can use and manipulate in a controlled fashion to allow them to continue testing.  Using the example above, the front end team has a set of data they need.  Presumably there is an object that represents that data and a service around retrieving that data.  The front end team in this scenario would mock the data object. That data object would be volatile (still under development by the data team) but the front end team would want to be able to create their own tests which would be dependent upon it.  Enter mocks. This way the front-end team would be able to stress different interactions with the data without having the data layer delivered.

Mocks do not replace communication in the software development process.  If the front end team does not speak with the data team, it is very well possible that the data they get won’t even be the data they need, even with great tests around it. Mocks are successful when dependent agile teams work together to understand their interactions and can agree on some interfaces or test contracts. This allows the teams to continue their work in parallel.

 

Ready to get your hands dirty? Here are some great links:

 

googlemock – Google C++ mocking framework

EasyMock – mocking framework for Java –  Great EasyMock example by Michael Minella

Mockito – mocking framework for Java — Great Mockito example by Brett Schuchert

Rhino - mocking framework for C# — Rhino example by Isiah Perumalla