agile top banner

Adopt TDD for a smooth Scrum experience for your teams

Read it in 0 Mins

Last updated on
27th Aug, 2019
22nd Dec, 2017
Adopt TDD for a smooth Scrum experience for your teams

As you might already be aware, TDD stands for Test Driven Development. Adoption of TDD is a key factor for the success of your Scrum teams and in turn for your success as a Scrum Master. I will explain the why and how of TDD and how it helps smoothen Scrum experience in this article.

As you might be already doing, with Scrum approach, there are no grandiose design sessions/detailed designs done up-front but the focus is getting working pieces of code out and fail fast if there are any issues. The key reason being – designs change as you progress with the development of code and your code should be flexible enough to absorb major or minor changes until towards end of the development. If complete designs are done up-front to the detailed level, code is written assuming the designs are concrete and becomes rigid. This type of code can’t accept changes easily and as every developer is aware, changes to requirements are very common during implementation cycle. 

A framework that can help the Scrum teams accept the changes easily, make the changes and quickly assess the effects of these changes can help alleviate these issues. Once the impacts are clear, it doesn’t take too long to get the implementation back to stable state. TDD provides one such framework for Agile development. 

TDD (Test Driven Development)

Following is the broad outline of adopting TDD during development. I will take developing APIs for a product as an example, which can be easily extended to other use cases.

  • Do a high-level design of the components and APIs you are going to have. Prepare the interfaces against which you can write tests.
  • Adopt a framework like JUnits for writing your test cases. Get the developers up-to-speed on writing these unit tests.
  • For whatever components you are developing APIs, create a skeleton of tests and test cases. Normally, you would write a set of positive and negative test cases. This is the first step even before you write a single piece of implantation code. Make sure majority of the unit test cases are covered in this round of skeletal test cases.
  • Implement the APIs with no code, i.e. now they can be called but will not yet return proper values. For example, they may return nulls where an object is expected.
  • Since implementation of APIs is not yet ready, all of your tests will fail. That’s ok to start with.
  • Now as development of APIs progresses, test cases will start to succeed. At the end of, say, sprint #1, you may have 20% of your test cases working. In parallel, add more or update your test cases to handle more complex usages of the APIs.
  • The goal is to get 100% success rate of test cases, which should happen as the development is completed and more code is added.

For example, this is how your tests may look to begin with:

    public void testSingleObjectCreate() throws Exception
      Object a = createObject(...);

    public void testMultipleObjectsCreate() throws Exception
      Object [] objs = createObjects(...);

    public void testSingleObjectReplace() throws Exception
      Object replacedA = replaceObject(a);

    public void testMultipleObjectsReplace() throws Exception
      Object[] updatedObjs = replaceObject(objs);
    public void testSingleObjectDelete() throws Exception
      boolean deleted = deleteObject(a);

Note that all of these tests will fail to begin since APIs are not yet implemented. Your goal is to get all of the tests passing incrementally, by implementing the underlying functionality.

Once this set of test suites are built, they can become part of a continuous integration setup and are run as soon as changes are submitted to the source code system, giving an immediate feedback on whether there are test cases failing because of new code that is delivered.

Following diagram summarizes this approach:


How does this help your Scrum team?
TDD can augment Scrum processes in 3 ways:

  • Ability to absorb changes to code on a continuous basis.
  • Fail fast: Failures happen sooner than later.
  • Reduce technical debt

Let me cover details of each of these points.

Ability to absorb changes to code on a continuous basis: As a Scrum Master, your job is to make sure that the working code gets produced at the end of each sprint and minimize the technical debt for going forward. At the same time, you want the code to be flexible so that changes can be accepted on a continual basis to improve the existing code or be able to absorb new changes, based on product owner or stakeholder feedback. This is especially important since you don’t get into detailed designs up-front and absorb changes as you progress to make implementation better. Having the suite of unit tests is one of your weapons in the war chest to make this happen – after all, code which is delivered at the end of release but doesn’t address the key requirements is of not of much use.

Take this case – in the midst of development, one of the developers changes the inner workings of one of the APIs and now it fails for a given set of inputs (which used to work before the change). Now your unit test which depended on the success status of API starts to fail, giving you an immediate indication of the change. However, developer can take the risk of the change, knowing that the test framework will catch any side effects of such a change.

As a second case, say half-way through the development cycle, there is a need for major change that impacts majority of the components. Unless you have a suite of test cases backing you, you just don’t know the impact and how much additional work is possibly required. (Knowing your developers, you know how hard it is to get a proper estimate of additional work!). Instead, now you can depend on your test suites and see how many are failing when the changes are put in place – if there are a large set of test cases failing, you are most likely looking at a larger impact change to the whole sprint and need to re-access the scope and priorities. Additionally, it makes everybody in the team aware of the impacts. 

Fail fast - Failures happen sooner than later: Adopting TDD facilitates one of the key principles of Scrum – fail fast. With TDD, you start with failing tests, make them work as you progress and make sure they won’t fail again due to some unexpected changes. If there are such failures, your TDD set of tests alert you immediately. Knowing there is such a framework, developers will be more open to changes – since failures are caught immediately. Overall, this becomes a mechanism which gives a quick feedback on the impacts of a change and makes developers open for adopting the changes rather than shying away from taking the risk of late changes to the system.

Reduce creation of Technical Debt: If developers can’t absorb changes fast enough, you will run out of time during sprint to do further changes. Pushing required changes out of sprint and eventually out of a release leads to the technical debt of future changes and re-work, which is not a desired outcome for any Scrum Master. Having a framework to facilitate quick changes avoids creation of technical debt.

Key is to start with TDD from day one
One of the key factors is to start with TDD from day 1 – it must not be an afterthought to be added after the code implementation. For any new code, tests should be written first, let them fail and implement code to make the tests work. For a Scrum Master, it is a key that developers are creating tasks to add unit tests for a given user story and have mechanisms in-place to continuously validate the code using build frameworks.

Combining TDD with Code coverage can be very powerful
TDD approach when used along with code coverage tools provides a very powerful combination to make sure your code base is stable all the time and all parts of the code are being tested. Greater the code coverage, better confidence you have to do drastic changes to your implementation code.
For example, the following screenshot of code coverage shows which parts of the code are being exercised (green) versus which are not (in red). More unit tests need to get added to provide coverage for the code paths not being tested.

Adopting TDD for existing products
TDD can be adopted for existing product code as well, which lacks unit test coverage. It is not usually productive to add tests for existing code unless major changes are planned. Tests can be added to the incremental functionality that is being added, being aware that you may impact the existing code and may not know if you have caused failures in the already existing code.

TDD Tools

  • There are several tools that are available in the market, which help in TDD adoption.
  • For unit testing of Java code, JUnit framework is the best choice.
  • For continuous build and test, frameworks like Cruise Control or tools like Jenkins can be used.
  • Code Coverage can be analyzed using tools like Emma and Clover. These have Eclipse plugins available as well.

In conclusion, adopting TDD goes a long way in ensuring code quality is maintained in the long run and changes can be done to the codebase ensuring continuously working software. This essentially gives control for your Scrum teams to manage the software better and address the end user needs quickly.


Mohana Kera

Blog Author

Mohana Kera is Senior technical leader with strong hands-on technology experience and in-depth experience in building Scrum teams and doing multiple product releases using Scrum. He has more than 10 years of experience in Agile methodologies and has worked with large cross-geo teams for product deliveries. He has effectively employed Agile(Scrum) method to build cohesive development teams, address efficiency issues and deliver projects on time and effectively, from a startup to multinational corporation, working with small to large teams.