RFC: article about testers using Ruby.

I've written a first draft of an article with several ulterior motives. One 
is to keep exposing testers to Ruby. Would anyone like to comment on my 
first draft?

I'm not assuming any programming background, so I'm simplifying or even 
distorting some truths in the interests of understanding. For example, it 
seemed easier to pretend there's more of a difference between getters and 
setters and other kinds of methods than there really is. And I refer to [0, 
29, 123] as a "list", since that notion is more likely to be familiar than 
"array". Am I going too far?

I'm also using win32ole. In the article, I write a test for Word. This is 
the first time I've used win32ole and only the second time I've talked 
programmatically to Word. How's my explanation? Again, I simplified a bit, 
and I might plain misunderstand something.

I'd need comments in about a week. I can supply a Word document. I should 
be able to provide PDF, but "print to PDF" has suddenly stopped working. 
Rebooting might fix it, but I suspect this NT machine knows I'm thinking of 
replacing it with a Mac.

-------------
Shunning the GUI

Graphical user interfaces make test automation hard. The problems are 
well-known. Specialized tools are required to drive the GUI. Those tools 
are often confused by the common programming practice of inventing custom 
user interface controls. When they are used in the simplest way, the tools 
lead to fragile tests that tend to break en masse when the GUI changes. 
Making the tests resistant to change requires elaborate and sometimes 
awkward testing frameworks.

Sometimes you must pay this price. Other times, there are alternatives. In 
this article, I'll show you one: testing through the program's scripting 
interface. My example will be testing Microsoft Word through the interface 
you'll often hear described as COM (Component Object Model) or OLE (Object 
Linking and Embedding). It's the interface that allows you to embed Excel 
spreadsheets in Word documents and vice versa. It's also the interface that 
allows you to write a Visual Basic or Perl program that uses Word to 
generate form letters. Since automated tests are programs, the same 
interface is dandy for testing.

This approach can be used with interfaces other than COM. For example, web 
services are becoming popular. These applications can be accessed from 
anywhere over the internet, and they usually use an interface called SOAP. 
Tests of such an application would look quite like what you'll see below.

This article will give you four things:

1.      A feel for what a scripting interface looks like.

2.      An example of how to write tests against one.

3.      Some exposure to the scripting language I think is best for 
testers, Ruby. I assume no programming background.

4.      An appreciation of the benefits of shunning the GUI.


--
"Act always so as to increase the number of choices." -- Heinz von Foerster