From: Brian Marick Date: 2002-04-18T13:45:27+09:00 Subject: RFC: article about testers using Ruby. --=====================_117125427==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed 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 --=====================_117125427==_.ALT Content-Type: text/html; charset="us-ascii" 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
--=====================_117125427==_.ALT--