How Test Driven Development helped our Software Integration Project
Test Driven Development (TDD) is an agile development technique in which developers write automated unit test cases before implementing product code and perform continuous refactoring until all the tests pass and meet coding standards. Over the past decade, several researchers have performed case studies [1, 2] which showed improvements in metrics such as code complexity and defect density when using Test driven approach. However the adoption of TDD approach has been rather sporadic in corporate world.
Possible reasons could be business driven crunch and strict project deadlines restricts engineering teams from adopting the TDD technique since practicing TDD increases the actual implementation time by 15 - 35% [2]. Another reason could be lack of education among development teams on how to adopt this technique for their teams. Software developers often have the question on how different is TDD from writing unit tests. This paper presents a real world case study to address the above mentioned concerns.
The paper highlights the positive experiences of using TDD in a software integration project I worked on at Groupon. The project involved integrating Groupon’s existing web application with that of OrderUps’ to add new functionalities to Groupon’s application. The paper highlights how the TDD approach helped the engineering team navigate through the various unknowns in this project and helped them deliver a quality product. It also highlights how practices such as multiple iterations, continuous refactoring and building large suite of tests resulted in quicker turn around time in test engineering and deployment cycles.
The paper also talks about how a software testers role aids in identifying functional test cases when the team practices TDD and how other dimensions of testing opens up for testers. This is followed by a brief discussion on case studies done in companies such as Microsoft, IBM to understand the impact of practicing TDD in real world projects.
Outline/Structure of the Talk
The session covers the following key points
- Introduction to Test driven development
- Discuss possible reasons for slow adoption in the industry
- Why TDD for a software integration project
- How practicing TDD helped our team for this project
- Discuss trade off and future improvements
- Role of software quality assurance engineers
- Discuss case studies where companies have practiced TDD to build products
- Suggestions to adopt this approach for your team/where to get started
Learning Outcome
Key takeaways
- Adopting TDD helped us deliver a product with incremental design changes that had fewer defect rate. It gave the engineering team a platform to build a product not solely based on a product specification document but by understanding the product from a user’s perspective.
- It was found fewer regression bugs were raised. A pleasing side effect is a regression test suite to reliably test backwards compatibility.
- Minimal manual testing got the team closer to continuous test engineering and deployment cycles.
- Minimal technical debt since code modularity and design falls into place with writing tests first.
Trade-off
This is a 6 week project in which an estimated increase of 25% of actual implementation time was
observed during the initial iterations pushing our deadlines by a week and 2 days.
How to adopt this approach for your team
- Arrange an TDD coaching session to get everyone excited and welcome initial team feedback. It can be hosted as a brown bag sessions if there are volunteers within the team to hold training sessions or by inviting an agile consultant.
- Adopt Pair programming to share knowledge among team members. This helps developers learns new techniques from each other fairly quickly.
- Plan on organizing a hackathon project for your team spanning a week approximately. Start with a small list of user stories that describe how an application should behave. Map user stories to a list of tasks and have each developer take one task.
- Encourage developers to concentrate only on one class to implement and one relationship to keep things simple at the start. Create a method stub for it and implement code necessary to pass the test followed by code refactoring. Once tests are green, cross the task off the developers list. Iterate this process with another task. Have the team do a few tasks in the week and discuss what worked and what did not.
- Specific tools required primarily depends on the programming language your project uses. Most unit test frameworks such as NUnit (.Net), JUnit (Java), QUnit (Javascript), ScalaTest (Scala) should fit the developers’ needs to write tests when practicing TDD.
Target Audience
Anyone working in software development team, Project managers, Developers, Testers, Product folks
Akshat s.p
