September 24, 2016

...Learn TDD with Codemanship

10 Great Reasons to Learn TDD

1. Rising Demand - Test-Driven Development has been growing in popularity over the last decade, with demand rising by a fairly steady 6% each year here in the UK. In 2016, roughly a quarter of all developer jobs advertised ask for TDD skills and experience. It's not unthinkable that within the next decade, TDD will become a mandatory skill for software developers.

2. Better Pay - according to data on itjobswatch.co.uk, the median salary for a software developer in the UK is £40,000. For devs with TDD skills, it rises a whopping 27.5% to £51,000. Overall, developer pay in Britain has been stagnating, with a real-terms fall in earnings over the last decade. Salaries for jobs requiring TDD skills have consistently outperformed inflation, rising about 4.5% every year for the last 3 years.

3. Better Software - the jury's not out on this one. Studies done into the effects of TDD show quite conclusively that test-driven code is less buggy - by as much as 90% less buggy. But that's not the only effect on code quality; studies done at the BBC and by Keith Braithwaite of Zuhlke Engineering show clear gains in code maintainability, with test-driven code being simpler and containing less duplication. Other studies show test-driven code tends to have lower class coupling and higher class cohesion.

4. Faster Cycle Times - the Holy Grail of Continuous Delivery is code that's always shippable, so when a feature's ready, the business can decide to release it straight away, instead of having to wait for a long and tortuous acceptance testing and stabilisation phase to make it fit for purpose. TDD, done well, delivers on this promise by continuously testing the code to ensure it always works. It's no coincidence that all the teams doing Continuous Delivery successfully are also doing TDD. TDD enables Continuous Delivery.

5. Sustainable Innovation - not only can TDD help teams deliver value sooner, it can also help them deliver value on the same code base for longer. I've seen some big organisations brought to their knees by the crippling cost of changing software products and systems, and having to rewrite software from scratch many times just to make small gains in new functionality. The technical benefits of TDD - continuous testing and cleaner code - tend to flatten out the cost of change over time, which typically rises exponentially otherwise.

6. It Doesn't Cost More - despite what some TDD naysayers claim, it actually doesn't cost significantly more to test-drive the design of your code, and in some cases improved productivity. Many teams report a slowdown when adopting TDD, and this is because of the not-inconsiderable learning curve. It takes 4-6 months to get the hang of TDD, and a lot of teams don't make it that far, which is why I strongly recommend adopting TDD "under the radar".

7. Puts The Problem Horse Before The Solution Cart - one of the biggest failings of software development teams is our tendency to be solution-driven and not problem-driven. TDD forces us to start by explicitly articulating the problem we want to solve, and then encourages us to find the simplest solution. As a result, test-driven code has a tendency to be more useful.

8. Free of Fear - I've seen first-hand the profound effect TDD can have on a developer's confidence. Firstly, using precise examples helps us to clear the fog that usually hangs over requirements, obscuring our view going forward. And continuous automated regression testing - a nifty side-effect of doing TDD - gives us confidence looking back that a change we make hasn't broken the software. The net effect is to make us more us more courageous as we work, more willing to try new ideas, less frightened of failing. Writing software is a learning process, and - to quote from Dune - "fear is the mind-killer".

9. Getting Everyone "On The Same Page" - exploring customer requirements using test examples is a very powerful way to clear up ambiguities and potential misunderstandings, by making everything clear and concrete. And not just for developers: testers, ops teams, UX designers, security experts, technical documentation writers, marketers... we can all benefit from these examples, getting the entire team on the same page.

10. A Gateway To High-Integrity Code - TDD, done well, can open the door to more advanced kinds of software testing at relatively low extra costs. For example, if you're in the habit of refactoring duplicate tests into parameterised tests, a few extra lines of code can add an exhaustive data-driven test. Increasingly, tools and techniques normally associated with high-integrity code (e.g., model checking) are being brought into the unit testing arena. NASA JPL's Pathfinder model checker, for example, can drive tests using JUnit Theories. And there are many versions of Haskell's QuickCheck being ported for other languages and xUnit implementations. Finally, after years of high-integrity software being a largely "academic" domain, we stand on the precipise of it going mainstream.

If you're interested in learning TDD, or are a TDD practitioner looking to distinguish yourself and advance your skills, visit www.codemanship.com







Posted 1 year ago on September 24, 2016