Decoding Test-driven Development

The Customer Care Technology team at the New York Times leverages scrum as their main process in order to plan sprints, go through the backlog, choose stories and assign a story to engineers who would then get the story done. Due to some unforeseen roadblocks, the stories, most often than not, would get pushed to the next sprint. To solve this, they started working together, swarming, for entire sprints and only tool on a small number of stories at a time. In swarming, agile development teams swarm on a story to complete it before moving on to a new story. One of the important techniques of swarming that they used was test-driven development (TDD) where you write the test, see it fail and subsequently write the feature. While one engineer wrote component tests and integration tests, another engineer worked on the underlying functionality.

Test-driven development has been an astounding solution for a large enterprise like the New York Times. But how did something like TDD emerge? Agile Alliance states that publication of ‘Test Driven Development: By Example’ by Kent Beck in 2003 gave rise to TDD.

Technology Conversations defines TDD as a “software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.”

It is different from traditional testing as is described in the following table.

There are several tools that can come handy for test-driven development. For instance, JUnit is a unit testing framework that is designed for Java Programming language. Or, you can use JMeter for load/performance testing. Mockito, as an open source testing framework for Java, can be of great help too.

Test-driven development follows a ‘Red-Green-Refactor’ cycle. At first, you create a test followed by just enough code to make the program compile but not enough to make the test fail. Then, you create just enough code for making the test pass. Now, the process refactoring ensues where you enhance the design of the code that you have just implemented. You re-run unit tests and the tests should pass. You, then, repeat the cycle every day between a few new tests a minute to a few minutes per new test.

Test-driven development follows a ‘Red-Green-Refactor’ cycle

The best thing about TDD is that it allows you to take small steps while writing software. For instance, you might have added some new functional code, compiled and tested it. Your tests might be broken by defects that exist in the new code and is much simpler to find and fix those defects if you have written three new lines of code than three thousand. Mostly the complaints of TDD are surrounding speed and the amount of extra code that is needed to make things work.

Joe Birch, a senior Android engineer at Buffer, says that TDD practice has actually reduced development time for his team. And Nitzan Blouin, Director of Engineering at Spotify, has implemented Test Certified for Data-Focused team which is a gamified, multistep program for getting teams to enhance their testing practices and test coverage. Arylee McSweaney, who handles Test Engineering and Strategy at Etsy, says that focussing on test automation has helped Etsy to increase engineering productivity, enhance code quality and increase confidence in the features launched to the site.

Therefore, the very nature of TDD means that practising it makes your programming experience into a perpetual stream of moments when the steps of a test that had previously thrown error begin passing. The most transformative thing about test-driven development is that it is a more satisfying way to develop and you get a test suite at the end and a cleaner code that works.