Build/Test machine

I posted here about our plans for updating the ProSolv build process. It's been going pretty well; the hallway machine is up and running, although I had to bring a table from home to set it up on, and now someone wants to buy it from me :)

Builds are scheduled for 6 PM each night, and an automated test script runs all day. Right now we just have a single script that takes about 15 minutes to run. It's powered by Ruby and by AutoHotKey, which works nicely as an automator. I especially like that the scripts are simple text files.

A lot of people don't quite understand what I'm trying to do. They look at the machine and say, "What's the point of running a test that doesn't log any results?" The answer is, that there is a lot of importance to just exercising the UI. If we have a build one day where you click on a study image and the application crashes, this test process will find that.

Nevertheless, as long as this machine is running scripts, there's no reason for it not to log results. I thought for a while that I would have to add code to the application to write out sensible log results, which is not a process to undertake lightly, but it occurred to me recently that the GUI manipulations that the script is doing mostly result in predictable changes to the file system and database. So I spent a little quality time with Ruby's DBI and Test/Unit modules, and wrote up some assertions that will send an email to me at the end of the script if the database isn't in the state I expect. It's only a start, but now I can add more assertions in the middle of the process, or add new assertions as I extend the test scripts. It's coming together very nicely!

I'm thinking also about modifying the machine to alternate test runs with kiosk-style data updates, such as how many files were compiled last night, or how many support calls were handled yesterday. It'll be interesting to see how people respond to that :)

Icerocket tags
Prosolv
Medical Software
Agile
Software Development