Test Driven Development – But Why?

An introduction to the TDD methodology

Everyone knows that tests are needed, but do you know really why? What are the benefits?

smiling-business-person-300x199In the beginning of our projects, we are in a green field where every code we write is nice and works, the speed of the project is high, the number of bugs is low and developers and clients are happy.

As the project advance the code start to get messy, every time we have to make a change is harder, in more places and force us to hack our own code or add some nasty code.

manzanaAfter a few months our code is rotten, becomes rigid and fragile. The speed of the team decreases and the number of bugs increases. The developer is scared to introduce changes to the code and to refactor because he doesn’t know if he will break another functionality, all the bug fixes or changes to existing code are small hacks.

So the developer is scared to touch the code because it is too fragile, he needs some kind of protection that he doesn’t break any functionality. This protection are the Tests.

Imagine to have a suite of test that could detect the vast majority of the bugs that could be run just with the click of a button in a few minutes… this is what TDD aims for.

What is TDD?

Kent-Beck-ingeniero-de-softwareIt is an Agile methodology which consists in letting our tests drive the development of the product writing them first to force us to write the exact code that makes those test pass.

This technique was created/redefined by Kent Beck one of the 17 original signatories of the Agile Manifesto and is related to Test-First programming concepts of the Extreme Programming.

But why?

Reduce the debug time

imagesIf we have a complete suite of tests we keep writing and updating them and running quite often, every time there is a bug, this bug will appear in the test as an error, so is already spotted just when it was created, and it will be easier to fix since it is located in the code that we just wrote so it is fresh to our mind. You don’t have to spend hours debugging through the whole call stack to check when, where and about what is the bug.

Living documentation

imgresNormally when we try to use a new API we go directly to the examples of code that shows how to use the API, and sometimes we even copy & paste the example and try to tweak it to use it in our code. So well, the Unit tests are those examples. If you have a complete set of Unit test in your product you only need to take a look at them in order to know how your code works.

You have in your set of tests an example of every possible way to use your code. Is the perfect documentation that is reliable and is always updated.

The courage for change

hqdefaultThanks to the suite of unit tests that covers most of your code you can be sure that your code is working, this will eliminate the fear of the developer to change anything allowing him to clean the code and refactor freely. Tests stop the code from rotting.

Why to write tests first?

tddWriting tests first makes the production code testable. Ok that’s obvious but what is de benefit? If the production code is testable it means that it is decoupled, if you can test a part of the production code by separate in one unit test then that part is decoupled from the rest of the components. The more decoupled the system is the more flexible and extensible is.

You get a better design just by writing test first.

Normally if you write your tests after writing your production code they won’t be as complete as if they were written first because you already know your code works and it is boring to write only tests, sometimes you are tempted to take shortcuts and you miss some tests.

If you write the test first you are writing code to pass those test, so every line of production code is covered by a test. You trust your test, they are more complete than if you write them after.

And how do we do TDD?

It consists in a 3 phases cycle, known as red, green, refactor. This cycle must be very short and the iterations must be quite fast in order to not be much time outside of the green phase where all your code is working.

tdd-cycleThere are 3 phases:

Writing a failing test first.

Writing the production code to pass the test.

Refactoring the production and the test code.

In the Red phase we write a unit test that fails that will force us to write the production code that we want to write.

In the Green phase we are able to write the production code to make that failing unit test pass. We write no more no less.

In the Blue phase, when our production code works as desired, we clean the production and the test code, making it more sustainable, extensible, removing duplication, in other words, we clean the code.

The 3 laws of TDD.

TDD is a discipline, as any discipline it has a set of rules that for the beginners can sound a little extreme, but with time they will become more and more logical. Here are the 3 Uncle’s Bob TDD rules, read them well and understand them well:

• You are not allowed to write any production code unless it is to make a failing unit test pass.

• You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

• You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Follow these 3 rules and they will force you to write alternating between test and production code in short time periods and you will always have production code that is passing all the tests or at least was not long time ago.

At the beginning coding in the TDD way will be slow and hard, but with time you will change your mindset and you will be automatically thinking about features that your code should do, instead of solutions, writing tests for it instead of implementing the production code directly and thinking how to write your production code to be easily testable and decoupled from other functionality.

Most of the information was obtained from the teachings of Robert C. Martin Aka Uncle Bob in his videos. You can download his videos at CleanCoders.com and follow his company blog for more interesting articles 8thLight Blog.

Recommended lectures:

Clean Code – by Robert C. Martin


Growing Object-Oriented Software, Guided by Tests – by Steve Freeman and Nat Pryce


Test Driven Development. By Example – by Kent Beck



Our motto: Deliver with Efficiency & Quality

Over the past 10 years we have been involved in a whole host of CMS/DAM/web implementation projects of many different kinds (clients of different types and sizes, as a prime contractor, a vendor integration partner or onsite with the client’s teams), and throughout that time we have always stuck to a single mantra: deliver with efficiency & quality to guarantee maximum customer satisfaction.

No matter what constraints we have faced in terms of managing the different projects, we have had to adapt and adopt. It has never been our goal to simply turn up and impose our rules, and it goes without saying that project management is deeply intertwined with corporate governance and enterprise policies.

In that sense, our project managers have their own cultural backgrounds that constantly enrich our internal Project Management Practices. Their principal goal is to deliver “good work, on-time and on-budget”.

We have nonetheless had the latitude to come up with our own PM approach, notably for fix-time projects. We made the decision to rationalize our position by taking account of 2 fields of perception: observations and corporate values.

Perception is where you look and how you look.

Jim Denevan or how to leverage our perception


First of all let’s talk about our observations

  • A software development process should be undertaken within the framework of a broader business commitment. That is why it is vital we understand exactly where the needs are coming from.
  • A more easily accessible knowledge, a Do-It-Yourself attitude and the product-oriented marketing have led everyone to think solution before needs, and unfortunately the vital phase of defining the real needs is sometimes skipped altogether.
  • Methodologies and organizations are intrinsically linked by culture, people and processes.
  • Agile methods demand mature relationships between business and IT, something which is often underestimated.
  • Corporate governance policies demand structured and uniform reporting procedures in projects that influence the choice of methodology.
  • Profound shifts don’t happen overnight in big organizations.
  • It is important to remember what the initial idea was: why are you doing the task in hand?
  • We can’t expect an all-encompassing model from the start.
  • The same tool in a different context can generate different results.
  • The requester has a good reason for making his request. Respect that.
  • Academic project management methodologies offer a starting point, but sticking to them reduces the scope of possibility.

Now let’s us introduce you our values

  • A good working relationship with a client is based on a constructive company-2-company relationship, structured team-2-team cooperation and a fair individual-2-individual collaboration.
  • Remember that you will learn from your initial choices.
  • Share the same goals and support one other.
  • Resolve situations that sap your time and energy.
  • Choose the right tool for the right job.
  • Don’t use all the colours just because you have them on your palette.
  • Make sure you are on the right track.
  • Guarantee a common understanding.
  • Demonstrate agility with the product, the method, the organization.
  • There’s always somebody that will use your product, and somebody that will maintain your software.
  • Listen carefully and respect other people’s constraints.
  • There’s no bad methodology, there’s no best methodology, there’s no point confronting waterfall and agile. Choose whatever solution works best for the situation in-hand.

When you are playing the software development game your secondary goal is to setup to play the next game.
Alistair Cockburn, Agile’s father

For our project management we deal with 2 dimensions

Driven by our enlightened understanding and inspired by the values of objectivity, efficiency, openness and honesty, our project management approach has been broadened to encompass two dimensions.

A cooperation framework for a future proof collaboration

Focusing on controlled planning and on broad and transparent communication, this approach is used to build a relationship with the client during first-time projects, one-shot projects or when handling program management issues. Based on waterfall methodologies, the phases are clearly defined and sequential:

  • Initiation to guarantee a shared understanding of the needs , expectations and perspectives;
  • Planning to reach an agreement on scope and timing, organization and risks;
  • Controlled & Monitored Execution with open communication & fast feedback, with close cooperation during the testing phase.

The aim of this framework is to identify the best way of working together in conjunction with the client. The approach is consequently a circular one, paving the way for the next project by means of an extensive closure phase to assess lessons learned and review the next steps.

Graph_04-EN-2The method focuses on control and communication, which means that numerous deliverables are required:

  • Engagement framework
  • Project Statement Of Work
  • Functional Contract, Solution design & Detailed planning
  • Monitoring reviews
  • Issue tracking with JIRA
  • Product evaluation & acceptance report
  • Project closure record

A fast-delivery framework in a mature relationship

Usually adopted when a mature working relationship has already been established with the client over the course of previous projects, this light and agile method demands a clear commitment in terms of roles and responsibilities. Guided by iterative development and agile methodologies, this approach is based on iterative cycles backed by delivery contracts:

  • Inception to define high-level requirements & engagement;
  • Elaboration using the iteration plan;
  • Execution involving strong collaboration;
  • Transition to review delivery and acceptance;
  • On-going assessment for strategy assurance and scope refinement.

Graph_04-EN-1The method is suitable for product enhancements (change management) or large roll-out projects that involve adding new features to a central environment based on new needs highlighted by a country/division assessment. These iterative cycles can also be run in parallel within the framework of a larger program. That is why the method is based on a light and versatile organization:

  • One project master, responsible for scope, communication and planning;
  • One product owner, usually a client representative or a commission agent, who can make quick & firm decisions, ensure that the functional strategy remains consistent and accept the deliverables;
  • One technical owner who plans and takes action in order to deliver on-time (this is usually a lead developer who is directly involved in the build).

All kinds of additional players may get involved at specific times or for specific reasons. The initial statement of work is put together when the project first kicks off, and then all subsequent communication is handled through our JIRA environment until the project is formally closed and the evaluation reviews are completed.

Our years of rich experience have shown us that these 2 frameworks can cover most situations, as long as the client doesn’t ask us to follow their own policies. Project management is not a science, it is simply good sense driven by experience, basic techniques and positive collaboration.

Being Agile depends on mind, personality and organizational structure.

During the past years along with the advancement and integration of information technology and digital experience within the business processes of companies and organizations, a lot of management methodologies and definitions have been created. In order to form processes towards the goal of easing project management along with efficiency and successful results. It’s the golden era of certifications after all, expanding to a technical, non-technical and theoretical spectrum.

A lot of methodologies include the agile terminology. The importance of being agile is not something new but it is now being accepted and recognized by a wider group of professionals. The term Agile derives from Latin “Agilis” and the meaning is: “to do and act”. Throughout the years the meaning of agile has been also characterized by being quick or alert. Different approaches including almost every phase from business analysis to project closure and software development to quality assurance have emerged. Most of the approaches are very similar with comparable tactics, differentiating mainly on the new areas (business topics) of implementation. Being agile is not another new business process or methodology, it is a logical process of how things should be working. We can all retrieve agile implementation/behavior tactics and actions, before various methodologies became popular or recognized.

The success of any agile methodology requires the existence of specific personality quality assets and traits of the people that implement the methodology. A list of indicative traits follows:

  • Be Active and Resourceful.
  • Be Able to make Educated Guesses.
  • Have, share and Test ideas.
  • Research and Learn.
  • Elaborate and Analyze.
  • Communicate efficiently.

Specifically for the IT sector, Agile methods like Scrum can provide a framework, but:

  • It’s the programmer’s mind who creates software, write or do not write quality code.
  • It’s the business analyst’s mind that filters all necessary input from teh stakeholders.
  • It’s the project’s manager’s mind that keeps implementation aligned with the customer’s needs and within budget.
  • It’s the QA team’s mind that reviews and provides the necessary input for improvement and corrections.

There is need to train people for agility and help them follow agile methods but this is just a stepping stone within the organizational environment that should provide the personality and teamwork traits of agility. A provision that is not an easy and fast but an ongoing internal cultural change management process.

Another value point to mention regarding the success of being Agile is to know the form of Agility we implement. For example, we all know that the initial phase of requirements and design is an extremely important phase and the driving factor of success of any project. By omitting and not pay attention at this phase will lead 100% to an agile behavior (not agile good practices) that its goal is not to improve the product but to apply temporary fixes, correcting and hiding design mistakes and poor documented stakeholder requirements.

Thus we have to distinguish between agility that tackles and improves a project task and agility because of poor organization and design. These are completely different.

Another example is quality assurance, an integral part of every project’s implementation. A poorly executed QA means that the agile methodology implementation during development was either not efficient or overlooked. Again, we will be forced to take corrective actions with agile resolutions not towards a well-executed project but towards a project that will just pass the contract’s terms. The bottom line is that agility has many faces and we must try to “wear” the effective one. A lot of agile-inspired projects start out with great hopes and commitment to moving through projects in a fast and energetic way but they often end up embracing failure and unhappy customers.

According to Sutherland and his Agile manifesto the four basic tenets of Scrum that guide efforts to achieve quick turnaround of product development with high participation and quality assurance are:

  1. Planning Is Useful. Blindly Following Plans Is Stupid.
  2. Inspect and Adapt.
  3. Change or Die.
  4. Fail Fast So You Can Fix Early.

The Agile concept is cultural at heart and methodological on skin. It is impossible to apply any methodology within an organization if the general culture does not support it.  Agility should be applied to all functional levels of an organization. For instance in Finance, HR, Regulation, Production, Sales, Marketing not only IT. The reason is that every project within an organization internal or external is impacting parameters that are affecting more than the project itself. It is impossible to have agility in Sales and have an opposite attitude in Marketing.

Another major difficulty takes place through the usual scenario of involving more than one company in a project. For example the interaction between a software house using agile methods and a customer whose corporate culture puts more weight on forms, procedures, and meetings than on visible value creation that can be inspected at short intervals by users.

Work that does not produce real value is madness. The correct agile methodology of “working product in short cycles to allow early user feedback so we can immediately eliminate what is obviously wasteful effort” in this case becomes just a theory and Agile becomes another recent “cool” term to mention.

To summarize agility about culture, flexibility, attitude, personality and philosophy that leads to effective, beneficial and non-bureaucratic practices throughout the entire business.