TDD – Have a Common Understanding in the Team

Recently I’ve been paying more attention to my style and approach to  TDD, and in doing so, I’ve begun to notice a few interesting things which, to me, seemed natural and almost “part of the process”, but clearly thats not the case with everyone. When I start on a dev task I typically try to ask as many of the right questions(see my previous post about avoiding autopilot) before I set off diving into code. I like to set the expectations of what it is that needs to be achieved, which is perfect in the world of TDD, because ultimately your tests should be testing the expectations match what actually happens.

I’ve come to learn that this isn’t necessarily the same “naturally assumed” approach which other developers might take. And along with that, there is mostly a misunderstanding within the team about what constitutes a focussed test, as well as what constitutes the definition of a category of tests. i.e. What qualifies as a unit test vs an integration test? And when to use them?

An experiment – collecting opinions

I thought I’d embark on a quick experiment and ask colleagues around me what their view on TDD is. Not surprisingly, there were a lot of different views and almost everyone I spoke to had a somewhat different idea of what TDD should be. Some advocating integration heavy tests to ensure business scenarios work, others advocate unit tests for quicker feedback etc. But what I found most interesting is that the definition of what a unit, integration, functional, end to end tests varied depending on who I spoke to! It became clear that is was common place to hear different vocabulary being used to describe the same end goal. For example I’d heard the terms “system testing”, “integration testing” and “acceptance testing” as well as “UAT” to all mean the same thing!

Clearing the  air

Obviously its fruitless to be embarking on a TDD journey if everyone int the team has a different idea of what its supposed to be. Most of the time when you hear the acronym “TDD” its automatically assumed to be unit tests that you’re writing, and for the large part, that might hold true. But I’m going to include other categories of testing that I feel should form part of the TDD paradigm. The definitions I supply below are not to be taken as solid regimented definitions, but more a way for teams to have a common understanding of what each area of TDD you’re targeting.

The Definitions

So lets clear the air a bit and define what is what. I’m obviously not the first person to write about the difference between unit and integration tests etc, but here’s what I find works:

Unit Test

A test that focuses on a single segment of behaviour. i.e. test that adding money to an account increases the overall balance. These tests should provide feedback as quickly as possible, and must run on every code change. And most importantly, a unit test is not something that touches 3rd party libraries/frameworks or resources which you have no control over. This includes interactions with a database, files system, and network comms as an example. Some might dispute that interactions between classes or modules that even you have written would be dumped in the integration category, but I disagree.

Integration Tests

Focussed on ensuring aspects of your code that interact with 3rd party libraries/frameworks and resources interact in the way you expect them to. i.e. writing an export file to disk, or saving an entity to the database successfully. These tests probably wouldn’t be run quite as often as your unit tests, as they could become quite heavy over time as the application grows. Typically, in most organisations I’ve worked in, these tend to run on every continuous integration build, and not necessarily on every code change – which included changes made while developing.

End to End/Acceptance Tests

Ensures that a business feature works as expected. This could include real world business scenarios from either through an API that has been built, or even through the UI – although this could be a whole other topic for another time. The point is, these end-to-end tests won’t run as frequently, and they will only test the core business scenarios. They involve complete vertical calls, and tend to be very CPU intensive, and are known to take large amounts of time to run. Especially as the application grows. Typically, you would have these run once a day, perhaps on a scheduled nightly build. If you happen to have introduced BDD into your development environment, these would be the tests I would expect to see running here.

So in summary, the real point here is that I was a little surprised that still to this day, many developers have a different take on what TDD is, and how to approach it, which might be fine, but in order for a team to produce good quality solutions and efficient code bases, then at the very least these teams all need to have a common understanding of what sort of tests they’re writing. Without it, your on a road, that will end in pain. Big pain.


Avoid “autopilot” behaviour when developing

I love coffee. And there’s a pretty good coffee place close to where I work that I regularly frequent out of the addiction I have now acquired for caffeine. Not to mention that I may possibly  need it in order to turn me into a less “abrasive” individual in the morning. 🙂 For the passed week or so, the conversation has gone a little like this:

Barista: Hi there, what I can I get you?

Me: I’d like a medium white americano, to have in please.

Barista: Americano?

Me: Yes

Barista: What size?

Me: Medium please.

Barista: To take away?

Me: No, to have in.

Barista: Would you like milk with that?

Me: Yes.

Now, this happens almost every time I go, and it got me thinking about some particular traits I’ve picked up on while working with some inexperienced software developers. When given a requirement, they almost instantly go into autopilot, and just begin coding, not always asking the right (or even at all!) the much needed questions that they should. On the other extreme, as in the case of the barista, sometimes they ask all the questions which were already answered in the first statement! As you can imagine, both ends of the scale result in a lot of wasted time. Clearly this barista was(and still is!) on autopilot, just asking the usual questions, and not really listening.

Inexperienced software developers have a tendency to just want to get stuck in a code away. I’ve been there, done that, and also subsequently been burnt by it. Resist this urge. Don’t assume you know the domain well enough to begin coding. Look at the problem you’re trying to solve first. Listen to the requirement and the context its in, and try to ask the right questions, and especially try not to ask the same questions which have already been answered, except for in the case where you are confirming your understanding.

I honestly think that if every developer did this, fewer bugs, fewer misunderstandings, and fewer under delivering to expectations would occur. If you need a little help on fighting the urge to code, then I’d suggest that you use the 5 Whys approach. If anything, this approach should help you contextualise the problem, and promote a discussion to lead you to ask the right questions before rushing in to code.

Sony Xperia S – ICS Update Fail. No Call Volume.

Just a quick post to hopefully help those out there who have just updated to the latest ICS(Android 4.0.4 at the time of writing), and have a Sony Xperia S mobile phone.


After updating from Gingerbread(2.3.3) to Android ICS (4.0.4) on your Sony Xperia S, you loose in call volume. When making/receiving phone calls, you can’t hear anyone on the other end.


Plug in a set of earphones/headphones. Now unplug it. Problem solved!


For some bizarre and ridiculous reason if you open the LiveWare Manager application on the phone, after the update has occurred, you’ll notice that the Headphones item has a little green dot next to it indicating that headphones mode is activated, hence why you can hear sweet nothing when making/receiving calls.

The above solution worked for me, I hope it manages to help others out there frustrated by the same thing.

Stubbing void methods with Mockito

I’ve been meaning to post something about this topic for a while, but it seems to have been slipping my mind. This post is targeted at those of you who use Mockito for your testing(Mockito is brilliant btw, and I applaud the folks over at Mockito for making this library!)

One thing that I got in the habit of was typing the when(mockClass.methodCall(eq(arg1))).thenCallRealMethod() etc, you’ll soon notice that if you’re trying to mock a void method, intellisense in any of your IDE’s will probably fail to allow you to select the methodCall method. There is an answer, and its way better than what was suggested in earlier versions. There is now a suite of doAnswer, doCallRealMethod, doNothing, doReturn(object), doThrow(exception) and the list goes on.

If you’re struggling to mock a void method, this is how you should go about it. Assuming you have a class that you would like to mock:

public class SampleClass {
   private String defaultValue = "default";

   public String getDefaultValue() {
    return defaultValue;

   public void setDefaultValue(String defaultValue) {
    this.defaultValue = defaultValue;

Here is a test class, mocking the behaviour of SampleClass, and setting up the test so that calls to the void method setDefaultValue are actually called, and subsequently verified with mockito.

public class SampleClassTest {

  private SampleClass sampleClass = mock(SampleClass.class);
  private String newDefaultValue = "Changed";

  public void testOldWayOfVoidMethodMock(){

//   This is the old approach to attempting to mock void methods. I suggest
//   you avoid this in favour of the new method which is much
//   cleaner and more readable.

     stubVoid(this.sampleClass).toAnswer(new Answer() {
       public Object answer(InvocationOnMock invocation) throws Throwable {
         return null;



  public void testNewWayOfVoidMethodMock(){
//    Previously you would have been tempted to write something like
//    this to test void methods...
//    when(sampleClass.setDefaultValue(eq(newDefaultValue))).thenCallRealMethod();

//    However, this is how you should treat mocking void methods with
//    Mockito. Works with or without methods that require arguments
//    of course.



I’ve included two test methods to demonstrate the old suggested way, and the newly much more readable way. If you need more help then I suggest heading over to the mockito documentation which is pretty useful.

Back from India

So I’m back from India, and that was a life experience! The trip has taken it out of me, but what an extraordinary country. India, for someone who is going there for the first time, not knowing what to expect, can only be described as a complete and utter assault on every sense you possess!

But now back to reality. Not too long ago I was talking about going contracting. This is the month I go about taking the actual plunge, before I jet off again on a quick trip around Italy soon – I know I’m taking advantage of the time off to do some much needed travelling. 🙂

I promise more technical posts will follow! Watch this space.

Escaping to the Himalayas

As some of you might know, I’m a bit of a biker, and also a little bit nuts sometimes. When you combine these two things, you will end up with a crazy idea like going to the Himalayas and riding around there on a Royal Enfield. So that’s exactly what I’m about to do! 🙂

I’ve decided to sign up with Blazing Trails and do one of their tours from Manali to Leh. I’ve never been to India before, and I’ve also never done a bike tour like this before – complete bike tour virgin! 🙂 Oh and did I mention I’m going on my own, not knowing a soul on tour!? Yeah I’m definitely nuts! I’ll more than likely be offline for the majority of the time, so this is a quick post to say “See you in +/-2 weeks!”

I suspect that by the time I return, I’ll be completely exhausted, but would have gained a life time experience. Here goes nothing….

Appfuse – The defined artifact is not an archetype

If ever you run into an issue with trying to create a project from an appfuse archetype template inside your favourite IDE and recieve the following error message:

Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.2:generate (default-cli) on project standalone-pom: The defined artifact is not an archetype -> [Help 1]

Then rather go here: and run the command line version. It’ll save you the headache!