#define private public - Pasting my own dogfood (08 Apr 2006)

topic end
<!--
   * Set TOPICTITLE = #define private public - Pasting my own dogfood (08 Apr 2006)
-->

<style type="text/css">
pre {background-color:#ffeecc;}
</style>

%STARTINCLUDE%
<a name="08"></a>

---+++ [[BlogOnSoftware20060408][Pasting my own dogfood]] (08 Apr 2006)

<img src="%ATTACHURL%/copy.png" align="right" />
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 is a tempting opportunity to gripe about  [[http://openfuture.free.fr/madness/clipboard-inheritance.html][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 then, considering all the stuff I've written and forgotten about, who
knows if I'm really in the right position to cast the first stone! And
today doesn't feel like soapbox day, anyway. 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.

Clipboard code isn't too tricky to write. However, 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 ground, 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.

---
%STOPINCLUDE%

%COMMENT{type="below" nonotify="on"}%

---
to top
End of topic
Skip to action links | Back to top
You are here: Blog > BlogOnSoftware20060408

r1.7 - 16 Apr 2006 - 12:28 - ClausBrod to top
Blog