Log in

No account? Create an account
entries friends calendar profile adric.net Previous Previous Next Next
nil.enroll(aetheric_username, quantum_class_id)
yljatlhQo'! QIch lo'laltbebej!
My test environment for RT is starting to take shape
So, I'm a few baby steps closer to having a test environment for the work I'm doing with RT (the awesome Request Tracker software from Jesse and his bunch of misfit geniuses over at bestpractical.com) I'm not hacking on the code of RT directly, so my testing requirements aren't much aligned with those of the core developers or extension authors (who do make excellent use of the amazing variety of Perl testing frameworks and modules), so I been futzing around at it educationally and I thought it was time to share.

RT is a system which at a high level takes in email, processes it into the database, provides access to the data various ways (primarily a web site) and sends email out. Along the way it can do a lot of neat things and can hopefully exactly model business processes and workflow. And that is what I'm working on, rather than on RT itself. I'm working on top of RT, on the RT platform if you will.

Modelling business logic is done in RT 3.x via the Scrip system. Scrips are RT's automation configuration, expressed in Perl, and can either be input through the web ui or added to the code as Perl extensions. I expect to do some of each, eventually. Most of the scrips I'm working up will be for the correct filing, labeling, and distribution of the requests generated by these incoming emails.

So to be able to to test automated filing and distribution, I want to be able to send RT mail, watch what happens, check the various bins, take notes, make changes to scrips and quickly try again. The faster I can cycle through these steps the quicker I can come up with working business logic that we can deploy, ..., step three profit.

A production install of RT uses apache2, mod_perl, some database, a lot more Perl, and mail in and out, running on some kind of Unix (probably Linux) server. This would not be a good test environment even if readily available (and safe) because it's far too complicated and has too many moving parts that don't have anything to do with the experiments I want to run. And I don't want to expose this fragile thing to live email even if I was allowed to by local custom.

Here's what I have going so far for this:

  • mime_lite.pl : tiny Perl script using MIME:Lite from CPAN to generate full emails as text files

  • a development install of RT 3.8.6 on my workstation, configured with : ./configure --with-my-user-group --enable-layout=inplace --with-db-type=SQLite --with-devel-mode

  • which configuration1 simplifies a lot of things and enables more debug information

  • run with RT's standalone_httpd on a local high port

  • configured to send mail to /bin/cat >> mail.out instead of sendmail

  • injecting mail into RT just like a live system would, eg rt-mailgate -queue General --url < nursemail.txt

  • using tail to watch the logs as I poke things

  • Although I've been testing and breaking software my whole life I am still quite new to the craft of software testing and the concepts behind professional QA. In particular there is no innovation (yet) in what I am doing, but the tools of Unix are proving quite helpful and I'm happy with my progress so far.

    1: That configuration script is not from the excellent but dated book RT Essentials, or the wiki, but from some of Jesse's slides from a boot camp that turned up in Google's cache.

    Tags: , , ,

    2 comments or Leave a comment
    xantha From: xantha Date: December 31st, 2009 05:21 pm (UTC) (Link)
    hey, this is really cool.

    I deployed RT at work this year after getting really annoyed we didn't have any good way to track bugs/issues/etc but I've been thinking a lot about doing some stuff on top of RT too.
    adric From: adric Date: December 31st, 2009 06:55 pm (UTC) (Link)

    RT is pretty cool

    but not well documented. I'll probably post more and please let me know if I can answer any questions about it. I've had a little experience with it a couple other places and am really digging into it here at $new_job.

    While I'm here, happy yule, and not-being-2009 anymore! If it can't get any better can we at least get some better writers? These scripts suck.
    2 comments or Leave a comment