Test Driven Development – Apptivation debates its usefulness

The Apptivation offices are often a hive of bustling activity. Our developers are coding, our creative team are scribbling and our innovation team are dreaming. Occasionally there’s a game of table tennis thrown in to the mix. And we’re always talking – discussing a new API or some new hardware.

When the first iPhone 6 made its appearance in the office on launch day, there was an instant crowd and everyone wanted to play with it. As more devices surfaced, comparisons ensued, especially with the iPhone 6 Plus and many of the Android devices we have here too. Lively debate about screen sizes, thumb reach, glass manufacturing and app possibilities trickled across the whole company.

One of the things we pride ourselves on at Apptivation is our dedication to these debates. Talking with informed opinions from both sides of a divide, assessing direction for our teams and our work efforts.

Recently, we convened the development team and had a proper, structured debate around the seemingly-mundane topic of test-driven development (TDD). Chaired by one of our lead developers – Chris Bowers – a panel consisting of project managers, testers and designers listened to informed arguments both for and against test-driven development.

We heard from one side – discussing how TDD was invaluable in saving time, outlining milestones and breaking down the development process in to manageable chunks of targeted work, with rejoinders from the opposing team about moving goalposts, and how developing to meet a test could mean developing to fail as a product.

The strongest arguments focused around gaining a richer understanding of requirements for development – everything from functionality and interaction to user interface design and edge cases. TDD helps break down those larger pieces of a project and helps developers structure code more efficiently for future use, with refactoring and continued development.

Other benefits include a reduced amount of bugs, a shorter feedback loop, and potential cost savings with less time spent fixing problems post-development.

The discussion was charged from both sides, with chairperson and moderator tempering the heated elements and keeping the statements and responses neat and time-limited.

Ultimately, it was our team of observers who held the casting vote, and the ‘for’ side won out on the arguments over the ‘against’ team’s impressive (and sometimes hilarious) rejoinders. The whole team had spent time preparing arguments from each sides, and everyone left the debate more informed and more aligned around the benefits of TDD, and we’re putting these in to practice already with our existing and future projects.

The big question is what debate comes next?