Test::S...anslator(3)

πŸ’… NAME πŸ’…

Test::S...anslator(3) is the manual page (User Contributed Perl Documentation), and the module is Test::SQL::Translator β€” Test::More test functions for the Schema objects. No cap, it’s iconic. πŸ’…


✨ SYNOPSIS ✨

Here’s the little test script setup, bestie:

# 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"],
        },
    ],
});

πŸ¦‹ DESCRIPTION πŸ¦‹

Okay so the point of this module is to give you a set of Test::More tests for Schema objects. Testing a parsed schema becomes as easy as writing a perl data structure that describes how you expect the schema to look. It also hands you maybe_plan for conditionally running tests based on their dependencies. πŸ’–

Now the cute part: the data structures you give to the test subs don’t have to include all the possible values. You only need the ones you expect to have changed. Anything you leave out gets tested to make sure it’s still sitting at its default value. That’s a useful check that 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 β€” it’s giving real output inspo. 🌈


πŸ§ͺ Tests πŸ§ͺ

Every test starts with the schema object you wanna test as the first arg. Then comes a hash ref describing how you expect that object to look β€” and you only need to give the attributes you expect to have changed from the default. The 3rd arg is optional: it’s a test name that gets prepended to all the generated test names. πŸŽ€

The _ok subs are the main characters, and every one of them follows the same first arg + hash ref + optional test name setup from the paragraph above: 🫢

table_ok

field_ok

constraint_ok

index_ok

view_ok

trigger_ok

procedure_ok


πŸ’« CONDITIONAL TESTS πŸ’«

maybe_plan handles conditionally running an individual test. It exists so the test suite can still run 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. πŸ¦‹

Instead of a number of tests, you can pass undef if you’re using done_testing(), or 'no_plan' if you don’t want a plan at all. 😌


🎁 EXPORTS 🎁

Here’s the export list, bestie:

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

πŸ“ TODO πŸ“

Stuff the module wants someday:

Test the tests!

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 individual 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 it is 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. πŸ“„


πŸ‘‘ 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. πŸ’–


πŸ’– Okay bestie, that’s the whole vibe. This page comes from perl v5.42.0, dated 2024-12-12, and it’s the Test::S...anslator(3) manual page. Stay slay! πŸ’…βœ¨

πŸ“¦ where this page comes from