January 4, 2015
Real-world Examples of Polymorphic TestingA couple of people have asked me to clarify what I wrote in my brain-dump that touched on polymorphic testing on Jan 1st, requesting a couple of real-world examples.
Just to quickly recap, polymorphic testing is writing test code against abstractions and dependency-injecting the object under test so that we can run the same tests against different implementations. It's effectively a tool for testing Liskov Substitution.
I can think of two that I know have had a big impact, both of which are discussed in my new Advanced Unit Testing course.
Firstly, there's device drivers. If you're developing hardware to work with, say, Windows, then you may need to write custom device drivers to enable the software running on the PC to interface with the hardware.
Now, device drivers can do all sorts of things, from graphics and displays, to handling different kinds of inputs (mouse, tracker pad, pen etc), to acting as an audio interface for recording or monitoring sound, to talking to printers, and so on.
But all device drivers - regardless of what they're for - have to behave like good device drivers of the community (to paraphrase something my university landlord used to say to us), and play nice with the operating system and all the other device drivers.
And there are subgroups of device driver specialisation, too - audio, display, disk i/o, USB, Wi-Fi, etc etc.
Windows talks to these drivers through well-defined interfaces, and these abstractions have abstract rules that all device drivers must obey.
To certify your driver and hardware for use with Windows, they've made a suite of automated tests available as part of the Windows Hardware Certification Kit (HCK) (it used to be called the "Windows Logo" kit).
There are general tests that apply to all kinds of device driver, and specialised tests targeted at those subgroups like audio and video.
You will, one hopes, have your own tests that are specific to what your device does (e.g., testStartingOrgasmatronDisablesIncomingCalls() ). But shipping a suite of tests aimed at abstract device drivers helps ensure that, whatever it does, it does it without crashing your computer.
The second example is one I'm very familiar with as a user: Virtual Studio Technology (VST) plug-ins
A VST plug-in is a software library that can be inserted into the digital signal chain of an audio track for use in the creation of audio and music projects. In a digital way, they mimic how recording studios can insert an analog audio processing device into an audio analog signal chain (e.g., adding reverb to a guitar sound by routing the guitar signal through a reverb pedal).
VST plug-ins can do a wide variety of tasks, ranging from the simple reverb unit I mentioned, to simulating entire instruments (e.g., a digital simulation of a Minimoog synthesizer, or a sampled drum machine).
But, kind of like in real recording studios, it only becomes possible to route VST plug-ins together to do useful stuff when they present a standard interface through which the audio signals can flow. In the real world, many audio processing devices like reverbs and delays and guitar amps and synthesizers standardize on 1/4" audio jacks to allow us to route the signal from one device to another.
In software, VST plug-ins must present the standard interface that the recording software that hosts instances of them expect. And, just as with device drivers, there are rules that apply to this abstraction, regardless of what the plug-in specifically does.
When VST plug-ins don't function correctly as plug-ins, the host software is likely to crash. recording software can be notoriously unreliable.
Some VST plug-in developers have published unit tests suites to help other developers write more reliable plug-ins, like this one.
In both of these cases, it has served developer communities and their customers greatly to provide suites of tests that can be run against their abstractions.
Have a look around? What other examples of polymorphic testing can you find?
Posted 3 years, 1 month ago on January 4, 2015