In this guest post Ekaterina Novoseltseva explains why Test Driven Development (TDD) is important to get success with agile and explores the benefits that you can get from doing TDD.
Software developers know that there are a lot of complications on the way to the production and even more after adding changes to software. That’s why more and more companies start to shift to agile methodologies and TDD practices to achieve agility in software development processes.
Now you may see startups and big international companies like HSBC, Mango, Edreams, switching to agile methodology and agile project management. A lot of companies claim they are agile, but unfortunately each company understands agile differently. In Apiumhub we have worked for different companies in many industries and came to the conclusion that to be truly agile you need to do TDD and CI. In this article I will show the importance of TDD in agile development.
Essence of Agile
Before we dive into TDD, let’s look at the agile essence. Agile methodology means an iterative and incremental evolution. It helps teams in an evolving environment maintain a focus on the rapid delivery of value. It is based on rapid feedback, continuous improvement, flexibility, input of the team, and the delivery of results with high quality.
Normally the development process is splitted into short iterations called sprints. The optimal sprint is 2 weeks sprint. And the goal of each sprint is to complete a series of features defined as “user stories”. A user story is simply a description of the individual piece of functionality to be completed. For example: “As a registered user, I should be able to login so that I can view my account.”. From the list of features, user stories a backlog is created to help prioritize and manage developer’s work.
When we talk about agile, we talk about Kanban, Scrum, Extreme Programming, etc. Probably you have heard about Extreme Programming (XP), an agile software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. Out of Extreme Programming (XP) came unit testing and test driven development. Using TDD, software developers create unit tests when they program their code so that each unit test tests a small piece of software code to make sure that units perform as they are supposed to do. TDD allows teams to delete, add or edit functionalities in a fast and effective way.
Test Driven Development
It was Kent Beck, who developed the Test-Driven Development methodology. TDD leverages the short development cycles used in the agile methodology to apply iterative automated tests.
As in software development faults occur very often, TDD is a must in order to avoid discovering the problem during build stage; in stead discover it at the initial stage of the process.
Just like in agile, TDD consists of small iterations. In test driven development, you begin by writing the test cases covering the new functionality, then you write the production code necessary to make the test pass, and after that you refactor the code to make it more maintainable.
Don’t forget that in TDD you write the test before you write the code, it guaranties immediate feedback after changes are made. And here you are! TDD gives you a rapid feedback – crucial element in agile methodology. TDD gives you fast confirmation of whether your code behaves as it should. And that’s what you need to save time and money as well as fight for the first mover advantage! Basically you just launch high quality functionalities faster.
TDD really simplifies and speed up the process of developing new software, making it possible to launch a new scalable product as fast as possible with a solid Minimum Viable Product (MVP).
Continuous integration (CI) was also created for agile software development. It really works together with TDD. It organizes development into functional user stories. These user stories are put into smaller groups of work, sprints. The idea of continuous integration is to find issues quickly, giving each developer feedback on their work and TDD evaluates that work quickly. Each time, when you make new addition to the code, it’s test can be added to the suite of tests that are run when you build the integrated work. It allows you to make sure that new additions don’t break the functioning work of existing elements, functionalities, and developers whose code does in fact “break the build” can be notified quickly.
And now let’s look at the main benefits of TDD in Agile software development.
TDD Benefits
Rapid Feedback
I would say this is the biggest and most important benefit of TDD.
Doing TDD, software teams will have almost immediate feedback on the components they develop and test. This rapid feedback allows developers to fix the defects much faster compared to traditional methodology where code is tested days or weeks after implementation.
High Acceptance
TDD implementation is more likely to match the product owners vision when we are talking about user stories. Tests are easily generated from the acceptance criteria without interference from the constraints of the architecture design or programming constructs. TDD guarantees that the final version will meet the needs of product owner.
Clear Scope
TDD prevents having unwanted design or components in the product. It defines the exact set of required features. It makes it easy to identify redundant code, detect and eliminate unnecessary development tasks.
Customer-Centric
TDD is a customer-centric agile process. Each iteration is based on the rapid feedback, so you make sure you develop what the client wants and how he wants.
Focus
TDD helps keep productivity high by narrowing focus of the developers. Developers focus on one functionality and if it fails you work on it to make it pass the test. It forces software developers to think about smaller chunks of functionality at a time rather than the application as a whole. It allows teams incrementally build on a passing test, rather than trying to tackle the bigger picture from the get-go, which will probably result in more bugs, and therefore a longer development time.
Interface
As developers first write a test for a single piece of functionality, it means they have to think about the public interface that other code in an application which needs to integrate with.
Clean Code
Tests are interfacing with public methods, so developers have a much better idea of what can be made private, meaning there won’t be methods that don’t need to be public. In case of not doing a TDD, and developers make a method public, then they possibly have to support that in the future, meaning they have created extra work for themselves over a method that was only intended to be used internally in a class.
Dependencies
Dependencies developers mock would potentially be faster when running the tests, and not bring additional dependencies to a test suite, in the form of filesystems, networks, databases etc.
Safe Refactoring
Once developers passed a test, it’s then safe to refactor it. Even though developers work with legacy code, or code that someone else has written, and no tests have been written, developers can still use TDD.
Few Bugs
With better code coverage, developers save time on fixing bugs that would pop up and they would need to think how to solve the issues. So when a bug comes out, developers can still write a test first before attempting to fix the problem, to ensure that the bug won’t come up again.
ROI
The cost to TDD is higher in the short-term, when compared to not writing any tests, however projects that don’t have tests written first usually end up costing more in the long term.
Not having solid test code coverage, or any at all, makes project more risky in terms of having bugs and issues, which means that more time will be spent in the long run fixing them. More time equals more money, which makes the project more expensive overall. Also, TDD saves money on changing functionalities, because the tests act as a safety net which guarantee changes won’t break existing functionalities. As a result TDD shortens the development time to market.
Documentation
Tests can serve as documentation to a developer. If developers are unsure of how a class or library works, they may go and have a read through the tests. With TDD, tests usually get written for different scenarios, one of which is probably how developers want to use the class.
Better design software
With TDD software tends to be better designed, that is, loosely coupled and easily maintainable, because the developer is free to make design decisions and refactor at any time with confidence that the software is still working. This confidence is gained by running the tests.
Productivity
TDD reduces time spent on rework
Quality & scalable software
TDD allows developers to deliver maintainable, flexible & easily extensible code. Clean code which is ready for later growth.
New functionalities
TDD gives developers the ability to painlessly update their software to meet new business requirements or other unforeseen variables without breaking anything else.
Conclusion
Agile really transforms software development. And I hope that after reading this article you agree that being Agile means doing TDD and CI. Because in software development, the bigger the code base gets, the harder it gets to move further or to change the code because developers are scared to mess it up easily. But when developers do TDD, they have a safety net, allowing them to see very quickly what is the mistake, where it is and how it affects the system.
An agile company is the one that can get feedback fast and react to changing circumstances quickly. Test driven development is the methodology that makes adaptability, flexibility, maintainability and extensibility possible.
The Author of this guest post Ekaterina Novoseltseva is CMO & Agile project manager at Apiumhub, a software development company specialized in agile web and mobile app development.
TDD matters
Thank you Ekaterina for diving into TDD and explaining what makes it so important in agile development!
During the years there have been several investigations of the business benefits that agile has brought. Test Driven Development is one of the practices that contributes to the success of agile, the above list of benefits gives lots of reasons to consider it.
In my second book What Drives Quality I explore how quality plays a role in all of the software development phases. The book takes a deep dive into quality and provides a lean approach to quality which analyses the full development chain from customer request to delivering products. TDD is one of the many quality practices described in this book.
You can steer product quality in agile using Fault Slip Through. The approach is to reduce quality risks by deciding in the planning game when and how to invest in Quality. TDD helps you to find defects earlier and ensure that your software keeps working properly.
Have you used TDD? Which benefits did it bring you?
