- DESCRIPTION
- TESTING
  - WRITING TESTS
- FUNCTIONS
  - DATABASES
    - db_name
    - connect_sqlite
  - SHREDDER
    - shredder_new
  - SAVEPOINTS
    - savepoint_name
    - create_savepoint
    - restore_savepoint
  - DUMPS
    - dump_sqlite
    - dump_sqlite_exceptions
    - dump_current_and_savepoint
    - dump_savepoint_and_current

# DESCRIPTION

RT::Shredder test suite utilities

# TESTING

Since RT:Shredder 0.01_03 we have a test suite. You can run tests and see if everything works as expected before you try shredder on your actual data. Tests also help in the development process.

The test suite uses SQLite databases to store data in individual files, so you could sun tests on your production servers without risking damage to your production data.

You'll want to run the test suite almost every time you install or update the shredder distribution, especialy if you have local customizations of the DB schema and/or RT code.

Tests are one thing you can write even if you don't know much perl, but want to learn more about RT's internals. New tests are very welcome.

## WRITING TESTS

The shredder distribution has several files to help write new tests.

      t/shredder/utils.pl - this file, utilities
      t/00skeleton.t - skeleteton .t file for new tests

All tests follow this algorithm:

      require "t/shredder/utils.pl"; # plug in utilities
      init_db(); # create new tmp RT DB and init RT API
      # create RT data you want to be always in the RT DB
      # ...
      create_savepoint('mysp'); # create DB savepoint
      # create data you want delete with shredder
      # ...
      # run shredder on the objects you've created
      # ...
      # check that shredder deletes things you want
      # this command will compare savepoint DB with current
      cmp_deeply( dump_current_and_savepoint('mysp'), "current DB equal to savepoint");
      # then you can create another object and delete it, then check again

Savepoints are named and you can create two or more savepoints.

# FUNCTIONS

## DATABASES

### db_name

Returns the absolute file path to the current DB. It is `<RT::Test-`temp_directory . "rt5test" >>.

### connect_sqlite

Returns connected DBI DB handle.

Takes path to sqlite db.

## SHREDDER

### shredder_new

Creates and returns a new RT::Shredder object.

## SAVEPOINTS

### savepoint_name

Returns the absolute path to the named savepoint DB file. Takes one argument - savepoint name, by default `sp`.

### create_savepoint

Creates savepoint DB from the current DB. Takes name of the savepoint as argument.

### restore_savepoint

Restores current DB to savepoint state. Takes name of the savepoint as argument.

## DUMPS

### dump_sqlite

Returns DB dump as a complex hash structure: { TableName => { #id => { lc_field => 'value', } } }

Takes named argument `CleanDates`. If true, clean all date fields from dump. True by default.

### dump_sqlite_exceptions

If there are parts of the DB which can change from creating and deleting a queue, skip them when doing the comparison. One example is the global queue cache attribute on RT::System which will be updated on Queue creation and can't be rolled back by the shredder. It may actually make sense for Shredder to be updating this at some point in the future.

### dump_current_and_savepoint

Returns dump of the current DB and of the named savepoint. Takes one argument - savepoint name.

### dump_savepoint_and_current

Returns the same data as `dump_current_and_savepoint` function, but in reversed order.

← Back to index