Emily Bache is a Technical Agile Coach, she helps software development teams to get better at the technical practices needed to be agile, including Test-Driven Development, Refactoring, and Incremental Design. Emily is known as the author of the book, “The Coding Dojo Handbook”. For the second time, we organize a training course with Emily on Approval Testing. In this email interview we asked Emily what counts as legacy code, how to get into approval testing, and what her upcoming book will be about.
What is the optimal way of learning Approval Testing? What is the role of Gilded Rose Kata and other exercises in this process?
Approval Testing is a style and approach to writing automated tests that changes the way you verify behaviour. Basically, the ‘assert’ part of the test. As with any new tool or approach, it helps to have actual code examples to play with when you’re learning it. Once you start to see it in action then you’re bound to have lots of questions so it’s good to have people around you to discuss it with.
The Gilded Rose Kata is a fun little exercise that I maintain. It actually comes with approval tests, as well as being translated into about 40 programming languages. Whatever your coding background and language preferences, you can try it out and see how it works for yourself. When you’ve done that, you should easily be able to find other people to discuss it with, since it’s quite a popular exercise. For example Ron Jeffries recently wrote 13(!) blog posts about his experience with it.
You talk about refactoring and handling legacy code? What is actually legacy code? How would you define it?
Many developers struggle with code they inherited which has poor design and lacks automated tests. On their own, any one of those difficulties could probably be overcome, but in combination developers get a kind of paralyzing fear of changing the code. That’s how I would define legacy code. Code that you need to change but you’re afraid to in case you break it.
The antidote to that fear, I find, is feedback. High-quality feedback telling the developer when they are making safe changes. The feedback that gives them the confidence to improve the design and get in control. Approval testing is one way to get that feedback – you create regression tests that give you good information when behaviour changes.
What are the main things one should know before starting working with Approval Testing?
Since it’s a style of automated testing, it helps to have experience with unit testing already, perhaps with JUnit or similar. Approval Testing is often used in larger-granularity tests too, so experience with tools like Selenium or Cucumber would give you a good perspective, although it works a bit differently. This way of testing also fits extremely well into Agile methods, BDD, and Specification by Example. If you are working in a more traditional process, you may find adding these kinds of tests will help you to increase your agility.
For which situations is Approval Testing the best solution? When shouldn’t it be used?
If you’re facing legacy code, this can be a great addition to your strategy for getting control. I wouldn’t discount it for new development though, particularly if your system will produce some kind of detailed artifact where the user really cares about how it looks. For example I’ve seen this approach used to verify things like invoices, airline crew schedules, 3D molecular visualizations, and hospital blood test results.
Of course there are situations where I wouldn’t use Approval Testing, for example where the output is a single number – the result of a complex calculation. If you can calculate the expected result before you write the code, testing it with an ordinary assertion is a sensible approach.
Can Behaviour Driven Development be considered as the future of the industry and Approval Testing as an essential part of it? Why is it so?
The main priority of BDD is to improve collaboration and communication so we build the right software. In my experience Approval testing promotes good conversations. I’m giving a keynote speech at Cukenfest soon, (a conference about BDD), and I’m going to be talking about exactly this topic. For the test automation part of BDD most teams use the Gherkin syntax with Cucumber or SpecFlow. I think you can use Approval testing in a similar way.
You have been working on this topic for a while – what excites you about it?
There is so much potential for this technique! I see a lot of legacy code out there, and I see a lot of test cases that are unnecessarily difficult to maintain. If I can spread these testing techniques to even a small proportion of all those places it will make a huge positive difference to the quality of the software in the world.
You wrote a book about Coding Dojo, what can we expect from your follow-up book?
The motivation for my upcoming book “Technical Agile Coaching” is largely the same as for the previous one – I write for people who want to make a difference and improve the way software is built. In 2011 I published „The Coding Dojo Handbook“ which is full of advice and experiences setting up a forum for practicing coding skills. You can see my new book as an expansion of those ideas, seasoned with ten years of additional experience.
The focus of the coaching method I describe in the book is specifically on technical practices and how people write code. There are two main elements to the coaching. Firstly teaching techniques via interactive exercises and code katas. Secondly coaching a whole team to work effectively together as they do mob programming.
