10.6. RT s Test Infrastructure

 < Day Day Up > 

10.6. RT's Test Infrastructure

RT has a test infrastructure that you should use if you are doing core RT development. This helps ensure that any changes you make do not break existing functionality and adding tests for bug fixes or new features makes it easier for RT's core developers to integrate patches.

10.6.1. Running the Test Suite

There are two make targets that can run regression tests. Running the tests installs RT to whatever location was specified when configure was run. You may want to run configure with enable-layout=inplace, which will make RT simply use the files in the current location.

The regression target will use apachectl to start and stop the Apache server for some tests. It assumes that whatever apachectl it is configured to use controls a server that is configured to run RT. The regression-noapache target will start the standalone HTTP server on port 80 to run tests against.

10.6.2. Interpreting the Output

The tests use the standard Perl test harness. Tests are written in standard Perl and grouped into test files. As each test file runs, it prints a message showing the status of that file:

     lib/t/autogen/autogen-RT-GroupMembers_Overlay............ok 

This means that all the tests in this file ran correctly. If there are errors, these will be printed separately.

When all the tests have finished running, there will be a summary:

     Failed Test                       Stat Wstat Total Fail  Failed  List of Failed     -------------------------------------------------------------------------------     lib/t/regression/02basic_web.t     255 65280     1    0   0.00%  ??     lib/t/regression/03web_compiliati  255 65280     1    0   0.00%  ??     lib/t/regression/06mailgateway.t    15  3840    40   15  37.50%  4 7 9 16 18-19                                                                      21 25-26 28                                                                      32-33 35 38 40     lib/t/regression/08web_cf_access.    3   768     4    3  75.00%  2-4     lib/t/regression/19-rtname.t       255 65280     1    0   0.00%  ?? 

This shows which test files had problems and which tests failed. If the list of failed tests is simply ??, that means that the test file probably died before generating any output.

10.6.2.1. Running an individual test file

If you want to run a specific file, you can use the prove utility that comes with recent versions of the Test::Harness module. Before running tests, you should clean out the test database by running make regression-reset-db. Then you can use prove to run a single file:

     prove -Ilib -v lib/t/setup_regression.t lib/t/regression/19-rtname.t 

The -Ilib switch adds lib to Perl's library path. You should change this to the appropriate location. The -v switch turns on verbose output. This is helpful for fixing individual test failures. The first test, lib/t/setup_regression.t, ensures that the environment is ready for further regression tests. This should always be run before any other individual tests. After that, simply put the path(s) of the test file(s) you want to run.

10.6.3. Tests Extracted from Modules

If you look inside an RT core module like lib/RT/User_Overlay.pm, you will notice sections like this:

     =begin testing           ok(require RT::User);           =end testing 

Code inside this block will be extracted and turned into a test file when you run make regression. This is done with the testify-pods make action, which can be run separately. If you are working on the RT core code, you are encouraged to add tests to these blocks. Ideally, there should be one test block per method, though not all methods currently have tests.

Tests extracted from modules all share a single lexical scope, so a test that occurs later in the file can refer to variables created previously.

The tests are extracted into lib/t/autogen, one file per module.

10.6.4. Writing Tests

When writing tests, you can use any of the testing functions provided by Test::More, as this is automatically loaded in each auto-generated test file. If you want to use other testing modules, you will need to load them explicitly.

10.6.4.1. What is a good test?

This is a big topic, and there are a lot of good books on testing that cover the topic in great depth. Here are some quick guidelines:

  • Test one thing at a time, which means test one method with one set of arguments at once.

  • Remember to test both success and failure conditions. If code should fail on certain inputs, make sure that it does so.

  • It's probably better to have too many tests rather than too few. Some redundancy in testing is not a bad thing, and it may even turn up odd bugs, for example a method that fails after being called several times because of changes in an object's internal state.

     < Day Day Up > 


    RT Essentials
    RT Essentials
    ISBN: 0596006683
    EAN: 2147483647
    Year: 2005
    Pages: 166

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net