|
|
| 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 => 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.
| |