Performance Based Testing
Building timing based tests to match your performance based goals.
Most of my recent work has been focused on improving the performance and scalability of our system. It’s fairly easy to get into the habit of just sticking your finger in the air and declaring that all the new stuff feels faster than the old stuff. But an aim without a target is just a vague intention; deliverables needs measurables.
My aim in this lump of epic refactoring is to meet a performance goal, and therefore I should test against it. You can call it Test (or even Metric) Driven Development- but ultimately you’re just proving that you’ve done what you set out to do.
Luckily you can achieve this sort of time based testing (to a somewhat, but relatively systematic, degree of accuracy) in node.js with the built in performance timer. This little code snippet outlines how to do it against a promise function with a standard Mocha/Chai setup:
Having a test like this brings a good few benefits. The most obvious of which is a target it work to- obviously you could optimise the code to buggery (technical term), but if you’ve made the grade, there’s probably something more important for you to work on.
Adding simple performance testing also also ensures that, as the service evolves, over time, it remains within this performance goal; defending against the tendency for complexity to creep in without consideration for system reactivity.
Perhaps most interesting, though, is that it encourages you to define performant. Simply wishing something to be harder/better/faster isn’t a massively useful target, and knowing what the ‘good’ looks like will help you find compromises. For example- the functionality I’m currently working on will run on a high throughput Kinesis shard- which means my definition of performance is 1000 records/second (an AWS limit.)
So my lesson for today?
Take aim, before you fire; performance is just another requirement, to be defined, measured and met.
