Johnny Halife’s Blog

Last week I was posting about TDD and CAB and How to write MVP using TDD. This time I’ll focus on How does TDD helps on programming decoupled components?. I want to thank Gabriel Gonzales who gave me the idea commenting on this other post.

Let’s think about it in terms of a sample:

Suppose that I have Component (A) that uses the Component (B). I’m the developer in charge of the Component (A). The architect of my project has come with a fully detailed list of requirements for Component (A) including interactions with Component (B).

So if I’m doing TDD, I’ll try to map a requirement to a test. Since the requirement is specified for Component (A) the test also should be written on the same way. To write the test in a way that it’s accurated I’ve to be sure that once I implement the code for Component (A) the test will pass. What happens if Component B has a problem or it is wrong implemented. Is my code as bad as Component B since it doesn’t pass the test? How can I ensure that I’m really testing what I’ve written? The problem that we’re facing is depicted below.

To provide an answer to the questions above I’ll introduce you a concept: Interface Based Programming.

How does Interface Based Programming helps in this case?
Let’s think what happens if we create an interface for Component (B) [IComponentB] that has the methods and properties that it needs to interact with Component (A). After doing this, I can write the code of Component A to be based on IComponentB instead of the concrete Componet B object. Now what I’ve got is a dependency to an interface instead of to a concrete object.  The picture below displays the change that we’ve introduced.

So what? For testing porpoises I can create a new object called MockComponentB that implements the interface IComponentB. When I’m doing the test case I can pass this object to be used instead of concrete Component B. With this way of working we’re introducing another concept that is called Inversion of Control. With Mock Objects (that we’ve created for testing propoises) and the usage of IoC pattern we’ve successfuly decoupled the Component A from Component B. Since a Mock Object is a mimic object (for more info: http://en.wikipedia.org/wiki/Mock_object), the new testing surface that we’ve is depicted below.

As summary we can say:

• Once we introduced the Mock and the IoC pattern we’ve decoupled the Component A from Component B
• The surface of our test will have an accuracy of 100% of what we’re testing is really Component A.
• Working with the idea of minimizing the test surface leaded us to decouple our componets.
• Working in this way will lead us to have more decoupled component that takes our software to a modular approach where each component has an specific role or responsibility and also it could be exchanged with a new one or better one.

I hope this sample and this post helps you understanding how TDD will help you on programming decoupled components. One thing to have in mind is that making an abuse (for instance having a component for each method of the class or things like that) will take you from decoupling to over engineering.

Questions, feedback and comments are always welcomed.

“This post is in memory of my grandfather who taught me how to do the walk of life “

thanks,
~johnny