/ 
SQL-Translator-0.08_01
River stage three • 119 direct dependents • 269 total dependents
/ Test::SQL::Translator

NAME

Test::SQL::Translator - Test::More test functions for the Schema objects.

SYNOPSIS

# t/magic.t

use FindBin '$Bin';
use Test::More;
use Test::SQL::Translator;

# Run parse
my $sqlt = SQL::Translator->new(
    parser => "Magic",
    filename => "$Bin/data/magic/test.magic",
    ...
);
...
my $schema = $sqlt->schema;

# Test the table it produced.
table_ok( $schema->get_table("Customer"), {
    name => "Customer",
    fields => [
        {
            name => "CustomerID",
            data_type => "INT",
            size => 12,
            default_value => undef,
            is_nullable => 0,
            is_primary_key => 1,
        },
        {
            name => "bar",
            data_type => "VARCHAR",
            size => 255,
            is_nullable => 0,
        },
    ],
    constraints => [
        {
            type => "PRIMARY KEY",
            fields => "CustomerID",
        },
    ],
    indices => [
        {
            name => "barindex",
            fields => ["bar"],
        },
    ],
});

DESCSIPTION

Provides a set of Test::More tests for Schema objects. Testing a parsed schema is then as easy as writing a perl data structure describing how you expect the schema to look. Also provides maybe_plan for conditionally running tests based on their dependencies.

The data structures given to the test subs don't have to include all the possible values, only the ones you expect to have changed. Any left out will be tested to make sure they are still at their default value. This is a usefull check that you your parser hasn't accidentally set schema values you didn't expect it to.

For an example of the output run the t/16xml-parser.t test.

Tests

All the tests take a first arg of the schema object to test, followed by a hash ref describing how you expect that object to look (you only need give the attributes you expect to have changed from the default). The 3rd arg is an optional test name to pre-pend to all the generated test names.

table_ok

field_ok

constraint_ok

index_ok

view_ok

trigger_ok

procedure_ok

CONDITIONAL TESTS

The maybe_plan function handles conditionally running an individual test. It is here to enable running the test suite even when dependencies are missing; not having (for example) GraphViz installed should not keep the test suite from passing.

maybe_plan takes the number of tests to (maybe) run, and a list of modules on which test execution depends:

maybe_plan(180, 'SQL::Translator::Parser::MySQL');

If one of SQL::Translator::Parser::MySQL's dependencies does not exist, then the test will be skipped.

EXPORTS

table_ok, field_ok, constraint_ok, index_ok, view_ok, trigger_ok, procedure_ok, maybe_plan

TODO

Test the tests!
Test Count Constants

Constants to give the number of tests each *_ok sub uses. e.g. How many tests does field_ok run? Can then use these to set up the test plan easily.

Test skipping

As the test subs wrap up lots of tests in one call you can't skip idividual tests only whole sets e.g. a whole table or field. We could add skip_* items to the test hashes to allow per test skips. e.g.

skip_is_primary_key => "Need to fix primary key parsing.",
yaml test specs

Maybe have the test subs also accept yaml for the test hash ref as its a much nicer for writing big data structures. We can then define tests as in input schema file and test yaml file to compare it against.

BUGS

AUTHOR

Mark D. Addison <mark.addison@itn.co.uk>, Darren Chamberlain <darren@cpan.org>.

Thanks to Ken Y. Clark for the original table and field test code taken from his mysql test.

SEE ALSO

perl(1), SQL::Translator, SQL::Translator::Schema, Test::More.