Agile Testing & Importance of Stubs

Generally when we are trying to develop any application which exists in the ecosystem of other applications, we tend to spend a lot of time in solving dependency issues. There are many times when these external components would be down and would stop your related testing activity.
There is a smarter way of tackling with components which do not directly impact you - which is Stubs. It has it's own merits and demerits. I will be touching a little upon the importance of stubs from testing point of view. I am trying to highlight what I have been working on for quite some time.

Stubs as defined on wikipedia is a piece of code which represents other programming functionality. 

For around 7 months, I was working on a project where in we were trying to create a product/software (let's cal it X for sake of simplicity) which would fit in a stack of systems. Product X was dependent on other systems and would need to get it's input from bunch of other systems (let's say A & B as depicted in the diagram below). It would create an output in the form of XML which would be consumed by downstream systems. For the sake of understanding I have tried to portray the same in the block diagram.

So we had created stubs for system A & B which is quite evident from the diagram above. We had 2 environments for testing: 

• Local: where the app was working against stubs
• Integration: where stubs were replaced with actual components

Stubs actually removed the dependency and unblocks the QA activity. It also helped provide an early feedback to the development team. When we test a story against stub, we generally assume that the stubs are behaving the way the actual system would have behaved. I noticed that QA generally don't test the behaviour of the application by altering the stub, which I would encourage testers to do. Some time issues crop up when the third party app doesn't work the way it is intended to and we need to test how we are going to handle those failure scenarios. Stubs were also very useful during the showcases based on their response time and were very fast compared to actual apps.

Stubs typically also duplicate the testing effort. It needs testing team to test the same story twice. Each story was first tested in local environment and then in the Integration to ensure that it is working properly with the actual components.

However when you are following agile development methodology, I would suggets to use this approach of creating stubs and cut down any dependencies on external systems to fasten the story development and testing.