I’ve had the great fortune lately to have a little extra “uncommitted” time to spend exploring things that I’m interested in. On the top of my “to be explored” list is Approval Tests. I’ve been using it a bit over the last few months, but haven’t had time (until now) to dig deeper.
Approval Tests is an open source project with the purpose of providing a very simple way to solve some difficult testing problems. For example, one thing that Approval Tests makes easy is to provide characterization tests for legacy code.
I use characterization tests to lock down the existing behavior of code I need to work on – in other words, it is a test that proves the code does whatever it is currently doing so that I can refactor and clean it with confidence that I won’t accidentally change it’s behavior.
I first came upon the term in Michael Feathers amazing book (Working Effectively with Legacy Code), and have commonly used mock object frameworks to implement my characterization tests. However, that can be a complicated and time consuming process, and can sometimes require some refactoring to modify the code so it can be tested. Usually these are very safe refactorings – but can still introduce bugs. Another issue is that coverage is typically very localized to the method of interest and perhaps a few depended-on objects.
Enter Approval Tests: You get a lot of bang for the buck. For example, in one of the presentations I do (Code Excellence for the Average Programmer) I show how a real life project that had become impossible to maintain or enhance was revived using very simple code-cleaning techniques. It only took four unit test methods of a few lines each using Approval Tests to introduce sufficient code coverage to be able to confidently work on the project.
The essential concept of using Approval Testing this way is to allow the code you want to test to produce a result that you then capture by “Approving” it (which saves it). This approved result will then be used when you run the test to verify the results. Whenever anything changes, the test will fail and you’ll be shown the differences. Sounds simple, doesn’t it? And it is!!! Approval testing has a number of other uses, and perhaps I’ll have a chance to write about those sometime soon. I bet you can’t wait.
I encourage you to take a look the next time you get a chance: Approval Tests. The Approval Tests project was invented by Llewellyn Falco and Dan Gilkerson, and they invite your suggestions and help on expanding and improving it. Also, they have a talk they’ve been doing at various conferences and code camps. If you get a chance to see it I am sure you’ll find it an eye-opener. The next scheduled presentation is at the Silicon Valley Code Camp, and it’s called “Unit Testing the Easy Way”. I’ll be helping out on that one since Dan can’t make it, and I’m really looking forward to that.