Difference between revisions of "AutomatedTests"

From Request Tracker Wiki
Jump to navigation Jump to search
(Point readers to RT's official docs on testing)
 
(Remove old testing info and replace it with a pointer.)
Line 1: Line 1:
= Automated Testing in RT =
= <span style="font-size:13px;line-height:21px;">RT has a full test suite for ensuring functionality remains functional between changes. Best Practical smoke tests every commit on a variety of configurations, but it's good practice to run tests yourself if you're making changes to RT when writing a patch you plan to submit (or even one you don't!).  The test suite is quite large, and will take some time to run.</span> =
[http://bestpractical.com/rt/docs/latest/hacking Please see the official RT documentation for information on running the test suite. This information is incomplete] (and outdated; it's "make test" not "make regression").
<span style="font-size:13px;line-height:21px;">Instructions for running the tests are in RT's official documentation: </span>http://bestpractical.com/rt/docs/latest/hacking#Test-suite
 
== Introduction ==
 
When working with RT (and any large software system) one should really have a large set of automated tests. Best Practical likes patches that come with regression tests, etc etc etc. So write tests.
 
== Basic overview of test framework ==
 
The tests are kicked off by <code> make regression</code> this runs a full test suite, which may be more than you want.
 
Tests all use the <code> Test::More</code> perl module.
 
Tests from the "old" code are stored in the modules source code, in specific pod sections. They are extracted before being executed.
 
However, the preferred way of writing tests is now writing test scripts in <code> lib/t/regression/</code>).
 
Depending on which tests you run, you'll need different amounts of RT installed. Most things should need a working database. Some things will need a webserver.
 
Tests run smoothly as root, but this may be a problem for some users. Non privileged testing is achievable but your mileage may vary for some parts (tests related to mail gateway and web server).
 
== Details about writing tests ==
 
Using <code> Test::More</code> is pretty simple. <code> perldoc Test::More</code> should give you lots of examples, but here's a very simple test:
 
<nowiki>#!/usr/bin/perl
 
  use strict;
  use warnings;
  use Test::More plan =&gt; 2;
 
  is(1, 1, "one should be one");
  isnt(1, 2, "one is not two");
 
  </nowiki>
 
Writing tests is pretty much just like using the API. You call some whatever you're testing, then you use <code> is</code> or <code> isnt</code> to check that the result is what you expect. I believe <code>12-search.t</code> should be a pretty clear example.
 
== Tips and tricks ==
 
The full regression suite takes a while to run, and depends on lots of things you may not have installed. For example, when hacking on the search related tests, I really didn't want to install enough email pieces to run the email tests. So I made a <code> seph-test</code> target that depended on <code> regression-install regression-reset-db run-regression</code> I also moved most of the tests in lib/t/regression/ aside, so only my test was being run.
 
The regression tests will use the first perl in your path. So set <code> $PATH</code> appropriately or set <code> $PERL</code> to specify which <code> perl</code> to use.

Revision as of 13:26, 10 July 2013

RT has a full test suite for ensuring functionality remains functional between changes. Best Practical smoke tests every commit on a variety of configurations, but it's good practice to run tests yourself if you're making changes to RT when writing a patch you plan to submit (or even one you don't!).  The test suite is quite large, and will take some time to run.

Instructions for running the tests are in RT's official documentation: http://bestpractical.com/rt/docs/latest/hacking#Test-suite