AutomatedTests - Revision history

Brett: add docs

2021-12-17T22:05:51Z

add docs

Admin: 4 revisions imported

2016-04-06T20:03:18Z

4 revisions imported

← Older revision		Revision as of 16:03, 6 April 2016
(No difference)

67.183.142.187: Remove old testing info and replace it with a pointer.

2013-07-10T17:26:39Z

Remove old testing info and replace it with a pointer.

← Older revision		Revision as of 13:26, 10 July 2013
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.~~

203.214.145.245: Point readers to RT's official docs on testing

2013-07-10T07:35:51Z

Point readers to RT's official docs on testing

New page

= Automated Testing in RT =
[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").

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