A more reliable test bed

I've been working on putting together a test bed for the product that my company currently offers. My first cut at the test bed used AutoIt to drive the GUI and NUnit for the testing framework. This worked, but I felt it was too fragile (and perhaps too complex) for our QA folks. I therefore wrote an embedded test framework using my simple command parser that worked better.

First, it didn't require multiple executables (e.g., a separate application to drive the GUI using AutoIt). This reduced the complexity of the system, which was immediately reflected in the amount of documentation and support I had to produce.

Second, one can go off and do other tasks (e.g., read email) while the tests are running. This happened because the test bed no longer sent mouse and keyboard events to the application, so there was no contention for those resources. Responsiveness isn't what I would like, but that's the price I pay (until I get a machine with a multi-core CPU). Note that the window of the application running the tests may come to the top, so you may lose keystrokes if you are typing into another application. This shouldn't, however, interfere with the tests. E.g., the application with the embedded test-bed should ignore those keystrokes.

Third, I realized that this does away with synchronization issues. I am intimately familiar with the problems of dealing with variable wait times. For example, when using a GUI driver such as AutoIt or Silk, the testing application that drives the GUI may need to wait for a network to respond or for a long-running calculation to finish. It is usually unclear how long to allow the GUI driver to wait before assuming that something went wrong. Since this framework is "synchronized" with the application, this issue just disappeared. Admittedly, I should probably add some "time-out" feature (in the future) to handle any hangs, but I'll wait for the QA folks to ask for that before I put any effort into it.

Fourth, since there is no need for the test framework to wait, the test sequence will run faster.

The downside is that adding more tests requires some coding in the application. This, however, is usually straightforward. I find where the event from the GUI is handled and add a little hook function to call that same code, with parameters as necessary.

It's a pleasant suprise to have some positive unintended consquences, instead of (more common) negative side effects.

Ageism?

Don't bother applying for a job at Facebook if you got your college degree before 1980.

The dropdown for "Graduation Date" on their job application doesn't go back that far.

Addendum:

In an industry survey, a majority of technology companies candidly said they would not hire anyone over 40.

New York Times, article in "This Week" section on June 22, 2008, titled "For a Good Retirement, Find Work. Good Luck."

Today's lesson...

I went searching for a line continuation character in DOS. I needed to make my CMD scripts more readable (if such scripts can ever be made readable - I'll use Ant next time). Searching around I found that the caret ("^") was supposed to be the continuation character. I tried it and it didn't work at first, until I realized that I was using it in the middle of a quoted string.

Re-jiggered the long command to put the caret(s) outside of quoted strings and it works like a champ. Not that I want to claim to be an expert in CMD scripts...