Pasting my own dogfood (08 Apr 2006)
Simplicity often breeds success. The Windows clipboard is undoubtedly an example
for this. Even though fairly limited and brittle, it is probably
the most popular mechanism of data exchange in a computer user's
daily life - every time I copy and paste some text from here to there,
I'm using the clipboard.
(This would be a tempting opportunity to gripe about clipboard inheritance.
In my time as a programmer, I have certainly found way more jaw-dropping
instances of boneheaded copy-paste programming than I'd ever wish for.
But today is not a soapbox day for me, really. No, today I'll try to be
constructive, just for a change!)
Pretty much every application under the sun supports the clipboard,
and if you want to write a new application, you'll also want to
be able to export application-specific data to the clipboard in some
popular formats, or to import data from Office, your favorite audio
ripper software, or simply from Notepad.
But even though clipboard code is fairly straightforward to create, it isn't
all that obvious how you can test it effectively.
You can of course test clipboard functionality in your application
by mousing around: Run your app, select some data, hit CTRL-C to paste
data to the clipboard, hit CTRL-V to paste it back into your own
application again, select some other data, rinse and repeat. While this
roundtrip test certainly covers a lot of test cases, it has two fundamental
weaknesses: First, it assumes that your application understands the same
clipboard input formats which it produces for output, which is often not the
case. Second, this approach only verifies that your "copy" code is just
as broken as your "paste" code, i.e. that they make the same
assumptions about the clipboard and the format of the data stored there.
If the transfer works as expected, it either means that both copy and
paste code are correct, or it means that both code areas have symmetric bugs!
So to fully test clipboard functionality in an application, you better try
to interact with other applications. After all, this is the whole
original purpose of the clipboard. If exchanging data with other apps works,
then you know that you interpret certain clipboard formats
the same way other applications do, and can claim with confidence that
your application is interoperable.
However, running other applications as part of clipboard unit tests
poses its own challenges: For example, the remote application might be difficult
to automate because it does not have an automation API. Also, to run the unit tests
on any given test system, you'd have to install the remote application
on that test system first. Not exactly a tempting thought if the Windows
Installer file for that application fills 100 MB, or if the installation
process requires you to enter license codes.
This is the kind of situation I found myself in recently. In the next few blog
entries, I'll discuss a few ideas on how to tackle this problem.
Revision: r1.5 - 09 Apr 2006 - 20:30 - ClausBrod