![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
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 http://127.0.0.1:8888 < 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.
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:
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.