Adopt TDD for a smooth Scrum experience for your teams

TDD is an abbreviation used for Test Driven Development. It is used by major companies like Microsoft, Google, Facebook, or any other software development company to develop perfect software. The process of TDD starts with the testing process. In this process, the cases of the program are designed and used for identifying significant bugs related to syntax, logic, usability, security, compatibility, or functionality.

In other words, TDD helps assess each possible solution for the code by testing it with initial understanding and evaluating for errors. If any errors are found, the code is sent for rectification, and the bugs are replaced with a new debugged code. The CSM certification training will help you understand Agile and Scrum concepts better.

What is TDD in Scrum?

Scrum is software used for project management purposes and can be used in domains like research, sales, marketing, and advanced software development. The software helps the teams accept major or minor changes and develop a detailed level code satisfying all the test driven development scrum case requirements.

TDD in Agile methodology was born using the critical concepts of Extreme Programming and Agile Manifesto principles. The Agile Manifesto Principles instruct to break the process of software development into the following core values:

• Interaction about the process and the tools to be used.
• Prioritizing quality software over documentation.
• Customer feedback and handling of contract negotiations.
• Using an TDD in Agile Scrum approach for executing the change of plans.

Similarly, the TDD Agile Methodology approach follows extreme programming techniques by releasing the final software product only after it obeys or passes all the possible tests. This approach helps write a unit test case before creating the software code. The process of TDD comprises five steps:

• Insert the code for testing
• Execute all tests and check for the incorrect code ( Code with wrong output )
• Debugging process
• Rerun the code and restructure the code
• If the error persists, repeat it.

TDD in Scrum approach can help Scrum Teams in the following ways:

Allows to Execute Changes Continually

Scrum is flexible for all the changes that could occur. You can break these changes into test cases by implementing the TDD and Scrum approach. It helps divide a more significant problem or bug into more minor mistakes. Having the set of all test cases makes the design front look much more functional and efficient, thus delivering the result that satisfies all the essential requirements.

Assess the Risk with Changes

Consider a situation where a programmer changes a specific API of a machine learning software that gives blog content as an output. The programmer makes the changes such that after a certain point of time, the software crashes due to high time complexity. In such cases, using TDD and Scrum for problem-solving is the fastest solution.

The approach helps the software developer to check for unit tests, giving you an immediate indication of the change that has happened and allowing you to write a test framework that rectifies the side effects of such changes.

Reduce the Overall Costs

Businesses lose money after launching a failed product. It is because the consumers start losing interest or trust in the brand. This situation will never arise as a Scrum Team is equipped with the TDD approach. It is because the test driven development in Scrum does not allow the release of a software product if it does not comply with or satisfy major test requirements. Thus, rectifying the bugs before launch by facilitating quick changes, avoiding significant loss.

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:
    @Test
    public void testSingleObjectCreate() throws Exception
    {
      Object a = createObject(...);
        Assert.assertNotNull(a);
    }

    @Test
    public void testMultipleObjectsCreate() throws Exception
    {
      Object [] objs = createObjects(...);
        Assert.assertNotNull(objs);
    }

    @Test
    public void testSingleObjectReplace() throws Exception
    {
      Object replacedA = replaceObject(a);
        Assert.assertNotNull(replacedA);
    }

    @Test
    public void testMultipleObjectsReplace() throws Exception
    {
      Object[] updatedObjs = replaceObject(objs);
        Assert.assertNotNull(updatedObjs);
    }
    
    @Test
    public void testSingleObjectDelete() throws Exception
    {
      boolean deleted = deleteObject(a);
        Assert.assertTrue(deleted);
    }    

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

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 create 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 make 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.

Become a project management expert with our PRINCE2 online course. Develop the skills to lead successful projects and boost your career now!

Stages of TDD Adoption Process

TDD process is divided into five steps: 

Read, Understand and Process the Bug Request  

It is the first stage of the TDD adoption process and includes reading, understanding, and implementing solutions for the operation of the bug request. This step includes making a blueprint or chart about how to approach the problem in each step. 

Write a Unit Test Based on the Requirement 

This step involves breaking the bug into more minor unit test cases and writing the code based on the requirement for debugging. 

Run All Tests

Run the initial unit case and if it passes all the conditions, deliver the code; if not, start the debugging process again. 

Refactor

Make the changes to the code according to the error that occurs while running the code. 

Repeat

If the error continues, loop through the entire process again.

Conclusion

Adopting TDD for your scrum teams has many benefits. It can help businesses by bringing functionalities first and delivering a quality, clean code product. The approach has helped increase the programmers' productivity by allowing them to adopt the changes that occur regularly. However, learning this approach can be challenging as it has many complicated processes, like breaking the problem into test cases. Go for KnowledgeHut PSM training and gain mastery of Scrum and over the role of the Scrum master.