Test::...::Class(3pm)

🦋 Test::...::Class(3pm) 🦋

bestie, this is the manpage but make it group chat. every single technical detail is still here, periodt. 💅

---

🌸 NAME 🌸

• Test::DBIx::Class — easier test cases for your DBIx::Class applications. that's the whole vibe. ✨

---

✨ SYNOPSIS ✨

okay so here's the tea: imagine you're making a standard Perl testing script, like MyApp/t/schema/01-basic.t, and you run it from the shell with prove -l t/schema/01-basic.t or while make test is happening. That test script could contain this:

use Test::More;

use strict;
use warnings;

use Test::DBIx::Class {
    schema_class => 'MyApp::Schema',
    connect_info => ['dbi:SQLite:dbname=:memory:','',''],
    connect_opts => { name_sep => '.', quote_char => '`', },
    fixture_class => '::Populate',
}, 'Person', 'Person::Employee' => {-as => 'Employee'}, 'Job', 'Phone';

## Your testing code below ##

## Your testing code above ##

done_testing;

ngl, it looks like a lot of boilerplate, but bestie, sensible defaults are in place (the code example above shows most of the existing defaults) and configuration data can be loaded from a central file. So, assuming you put all of your test configuration in the standard place, your 'real life' example is going to look closer to:

use Test::More;

use strict;
use warnings;
use Test::DBIx::Class qw(:resultsets);

## Your testing code below ##
## Your testing code above ##

done_testing;

Then, assuming there's a DBIx::Class::Schema subclass called MyApp::Schema and some DBIx::Class::ResultSources named like Person, Person::Employee, Job, and Phone, it will automatically deploy a testing schema in the given database / storage (or auto deploy to an in-memory based DBD::SQLite database), install fixtures, and let you run some test cases, such as:

## Your testing code below ##

fixtures_ok 'basic'
  => 'installed the basic fixtures from configuration files';

fixtures_ok [
    Job => [
        [qw/name description/],
        [Programmer => 'She who writes the code'],
        ['Movie Star' => 'Knows nothing about the code'],
    ],
], 'Installed some custom fixtures via the Populate fixture class',

ok my $john = Person->find({email=>'jjnapiork@cpan.org'})
  => 'John has entered the building!';

is_fields $john, {
    name => 'John Napiorkowski',
    email => 'jjnapiork@cpan.org',
    age => 40,
}, 'John has the expected fields';

is_fields ['job_title'], $john->jobs, [
    {job_title => 'programmer'},
    {job_title => 'administrator'},
],
is_fields 'job_title', $john->jobs,
    [qw/programmer administrator/],
    'Same test as above, just different compare format;

is_fields [qw/job_title salary/], $john->jobs, [
    ['programmer', 100000],
    ['administrator, 120000],
], 'Got expected fields from $john->jobs';

is_fields [qw/name age/], $john, ['John Napiorkowski', 40],
  => 'John has expected name and age';

is_fields_multi 'name', [
    $john, ['John Napiorkowski'],
    $vanessa, ['Vanessa Li'],
    $vincent, ['Vincent Zhou'],
] => 'All names as expected';

is_fields 'fullname',
    ResultSet('Country')->find('USA'),
    'United States of America',
    'Found the USA';

is_deeply [sort Schema->sources], [qw/
    Person Person::Employee Job Country Phone
/], 'Found all expected sources in the schema';

fixtures_ok my $first_album = sub {
    my $schema = shift @_;
    my $cd_rs = $schema->resultset('CD');
    return $cd_rs->create({
        name => 'My First Album',
        track_rs => [
            {position=>1, title=>'the first song'},
            {position=>2, title=>'yet another song'},
        ],
        cd_artist_rs=> [
            {person_artist=>{person => $vanessa}},
            {person_artist=>{person => $john}},
        ],
    });
}, 'You can even use a code reference for custom fixtures';

## Your testing code above ##

and bestie, please go look at the test cases for more examples. 💖

---

💖 DESCRIPTION 💖

okay so the goal of this distribution is to make writing test cases for your DBIx::Class based applications easier. It does this in three ways. First, it tries to make it easy to deploy your Schema. That can be to your dedicated testing database, or a simple SQLite database. This lets you run tests without interfering with your development work and without having to stop and set up a testing database instance. no cap.

Second, we allow you to load test fixtures via several different tools. And last, we create some helper functions in your test script so you can reduce repeated or boilerplate code. slay.

Overall, we attempt to reduce the amount of code you have to write before you can begin writing tests. periodt. 💅

---

🦋 IMPORTED METHODS 🦋

okay bestie, these are the methods that just show up in your namespace the moment you use this module. No extra importing, no fuss, they're yours now. ✨

🌸 Schema

ngl you probably won't need this one directly in your tests — unless you've got some application logic methods chilling inside it. Then yeah, go off. 💅

🌸 ResultSet ($source, ?{%search}, ?{%conditions})

So like, you can import your sources as local keywords, but sometimes you need a specific resultset without importing it globally, and that's exactly what this is for. Use it like:

ok ResultSet('Job'), "Yeah, some jobs in the database";
ok ResultSet( Job => {hourly_pay=>{'>'=>100}}), "Good paying jobs available!";

Since this hands you back a totally normal DBIx::Class::ResultSet, you can just call the regular methods on it. No cap.

ok ResultSet('Job')->search({hourly_pay=>{'>'=>100}}), "Good paying jobs available!";

This is literally the same as the test above. Same energy, different spelling. 🫶

Also! ResultSet can be called with a "$source, [\%search, \%condition]" signature. Noted. 💖

🌸 fixtures_ok

This one installs fixtures and verifies that the install actually happened — whether they're inlined, pulled from a fixture set in a file, or coming from a custom sub reference. It takes three argument styles:

💜 coderef

Give it a code reference and it'll run it against the currently defined schema. This is the move when you need a LOT of control over installing your fixtures. Example:

fixtures_ok sub {
    my $schema = shift @_;
    my $cd_rs = $schema->resultset('CD');
    return $cd_rs->create({
        name => 'My First Album',
        track_rs => [
            {position=>1, title=>'the first song'},
            {position=>2, title=>'yet another song'},
        ],
        cd_artist_rs=> [
            {person_artist=>{person => $vanessa}},
            {person_artist=>{person => $john}},
        ],
    });

}, 'Installed fixtures';

That whole thing gets executed at runtime, and if there's an error it gets trapped, reported, and we just move on to the next test. Resilient queen. 👑

💜 arrayref

Hand it an array reference and it'll try to process it via the default fixtures loader, or through whatever loader you specified.

fixtures_ok [
    Person => [
        ['name', 'age', 'email'],
        ['John', 40, 'john@nowehere.com'],
        ['Vincent', 15, 'vincent@home.com'],
        ['Vanessa', 35, 'vanessa@school.com'],
    ],
], 'Installed fixtures';

This is such a good option while you're still building up your fixture sets, or when your sets are gonna stay small and never get reused across a bunch of tests. Gets you rolling without messing around with config files. Periodt. 💅

💜 fixture set name

Give it a fixture name — or an array reference of names — and it installs the fixtures.

fixtures_ok 'core';
fixtures_ok [qw/core extra/];

Fixtures get installed in the order you specified. Order matters, bestie. 🎀

💜 all of the above

All the different types can be mixed and matched within a single test file. Go wild. 🌈

🌸 is_result ($result, ?$result)

A quick little vibe check to make sure $result actually inherits from DBIx::Class, or that it inherits from a subclass of DBIx::Class. 💖

🌸 is_resultset ($resultset, ?$resultset)

Same deal, but for $resultset: quick test to confirm it inherits from DBIx::Class::ResultSet or from a subclass of DBIx::Class::ResultSet. ✨

🌸 eq_resultset ($resultset, $resultset, ?$message)

Hand it two ResultSets and it figures out if they're equal based on class type and data. This is a true set equality — it ignores the sorting order of the items inside the set. So no stressing about who's first. 🦋

🌸 eq_result ($resultset, $resultset, ?$message)

Give it two row objects and it makes sure they're the same. That's it, that's the method. 😌

🌸 hri_dump ($resultset)

Not a test! It just returns a version of the ResultSet that has its inflator set to DBIx::Class::ResultClass::HashRefInflator, which gives you back a set of hashes and makes it easier to stop issues. That return value is suitable for dumping via Data::Dump, for example. iykyk 💅

🌸 reset_schema

Wipes and reloads the schema. Fresh start, clean slate, main character energy. ✨

🌸 cleanup_schema

Wipes the schema and disconnects. Bye bestie, see you never. 👋

🌸 dump_settings

Returns the configuration and related settings used to initialize this testing module. It's mostly there to help you debug configuration trouble and to help the authors find and fix bugs. 🐛

Heads up: at some point this won't be exported by default, so don't use it for your real tests — just use it to understand what's going on. You've been warned! 😭

🌸 is_fields

A 'Swiss Army Knife' method for checking your results or resultsets. It tests the values of a Result or ResultSet against expected, using a pattern. And guess what — that pattern gets automatically created by introspecting the fields of your ResultSet or Result. 🧚

Example usage for testing a result:

ok my $john = Person->find('john');

is_fields 'name', $john, ['John Napiorkowski'],
  'Found name of $john';

is_fields [qw/name age/], $john, ['John Napiorkowski', 40],
  'Found $johns name and age';

is_fields $john, {
    name => 'John Napiorkowski',
    age => 40,
    email => 'john@home.com'};  # Assuming $john has only the three columns listed

When we need to infer the match pattern, we grab the columns of the given result but remove the primary key. And psst — this would also work:

is_fields [qw/name age/] $john, {
    name => 'John Napiorkowski',
    age => 40}, 'Still got the name and age correct';

Pick whichever method makes the most sense in your tests. Your tests, your rules. 💜

Example usage for testing a resultset:

is_fields 'name', Person, [
    'John',
    'Vanessa',
    'Vincent',
];

is_fields ['name'], Person, [
    'John',
    'Vanessa',
    'Vincent',
];

is_fields ['name','age'], Person, [
    ['John',40],
    ['Vincent',15],
    ['Vanessa',35],
];

is_fields ['name','age'], Person, [
    {name=>'John', age=>40},
    {name=>'Vanessa',age=>35},
    {name=>'Vincent', age=>15},
];

I find the array version is the most concise. 💅 But please note the match is NOT ordered. If you need to test that a given Resultset is in a particular order, you'll currently have to write a custom test. If you've got a big need for that, the author is willing to write a test for it, or would gladly accept a patch adding it. 🫶

You should go examine the test cases for more examples! ⭐

🌸 is_fields_multi

TBD: Not yet written.

<sad>Coming soon to a theatre near you.</sad> 🙈

---

👑 SETUP AND INITIALIZATION 👑

The generic usage for this looks like one of the following:

use Test::DBIx::Class \%options, @sources
use Test::DBIx::Class %options, @sources

Where %options are key value pairs and @sources is an array, as specified below. ✨

🌈 Initialization Options

The only difference between the hash and the hash reference version of %options is that the hash version requires its keys to be prepended with "-". If you're inlining a lot of configuration, the hash reference version might look neater — but if you're only setting one or two options, the hash version might be more readable. For example, these two are the same:

use Test::DBIx::Class -config_path=>[qw(t etc config)], 'Person', 'Job';
use Test::DBIx::Class {config_path=>[qw(t etc config)]}, 'Person', 'Job';

The following options are currently standard and always available. Depending on your storage engine (like SQLite or MySQL) you'll have other options too. 💖

• config_path — These are the relative paths searched for configuration file information. See "Initialization Sources" for more.

In the case where we have both inlined and file based configurations, the inlined one is merged last (meaning it has the highest authority to override configuration files). 👑

When the final merging of all configurations happens — both anything inlined at 'use' time and anything found in any of the specified config_paths — we do a single 'post' config_path check. This lets you add a configuration file from inside a configuration file. For safety and sanity, you can only do this once. This feature makes it easier to globalize any additional configuration files. For example, the author often stores user specific settings in "~/etc/conf.*". This feature lets them add that into their standard "t/etc/schema.*" so it's available to all their test cases. 🎀

• schema_class — Required. This must be your subclass of DBIx::Class::Schema that defines your database schema.
• connect_info — Required. This accepts anything you can send to "connect" in DBIx::Class. Defaults to: ['dbi:SQLite:dbname=:memory:','',''] if left blank (but see 'traits' below for more). ✨
• connect_opts — Use this to customise connect_info if you've left that blank in order to have the dsn auto-generated, but you need extra attributes like name_sep and quote_char.
• deploy_opts — Use this to customise any arguments that are to be passed to "deploy" in DBIx::Class::Schema, like add_drop_table or quote_identifiers.
• default_resultset_attributes — Lets you specify default_resultset_attributes to be set on the schema. These get used when creating all new resultsets. This is typically done to enable caching or turn on the software_limit flag. 💅
• fixture_path — These are a list of relative paths searched for fixtures. Each item should be a directory that contains files loadable by Config::Any and suitable to be installed via one of the fixture classes. 🦋
• fixture_class — Command class that installs data into the database. It must provide a method called 'install_fixtures' that accepts a perl data structure and installs it into the database. It must capture and report errors. Default value is "::Populate", which loads Test::DBIx::Class::FixtureCommand::Populate, which is a command class based on "populate" in DBIx::Class::Schema. 🔥
• resultsets — Lets you add in some result source definitions to be imported at test script runtime. See "Initialization Sources" for more. ⭐
• force_drop_table — When deploying the database, this option lets you add a 'drop table' statement before the create ddl. Since this will return an error if you attempt to drop a table that doesn't exist, this is off by default for SQLite storage engines. You may need to enable it if you're using the following 'keep_db' option. 💀
• keep_db — okay so by default your testing database is “cleaned up” after you’re done. 💅 That drops all the created tables (but rn it doesn’t delete any related files or database users, if any). If you wanna keep your testing database after all the tests are run, set this to true. And if you do, you may also need to set the previously mentioned option force_drop_table to true as well, or we’ll attempt to create tables and populate them when they’re already populated and created. 😭
• deploy_db — by default a fresh version of the schema is deployed when Test::DBIx::Class is invoked. ✨ If you wanna skip the schema deployment and instead connect to an already existing and populated database, set this option to false. simple as that.
• traits — Traits are Moose::Roles that are applied to the class managing the connection to your database. If you leave this option blank and you don’t specify anything for connect_info (above), we automatically load the SQLite trait (which can be reviewed at Test::DBIx::Class::SchemaManager::Trait::SQLite). This trait installs the ability to automatically discover and deploy to an in memory or a filesystem SQLite database. If you’re just getting started with testing, this is probably your easiest option. 🫶

Currently there are only three traits, bestie:

1. The SQLite trait just described (and since it gets automatically loaded you never need to load it yourself).
2. The Test::DBIx::Class::SchemaManager::Trait::Testmysqld trait, which is built on top of Test::mysqld and allows you the ability to deploy to and run tests against a temporary instance of MySQL. For this trait MySQL and DBD::mysql need to be installed, but MySQL does not need to be running, nor do you need to create a test database or user.
3. The third one is the Test::DBIx::Class::SchemaManager::Trait::Testpostgresql trait, which is built on top of Test::Postgresql58 and allows you to deploy to and run tests against a temporary instance of Postgresql. For this trait Postgresql and DBD::Pg need to be installed, but Postgresql does not need to be running, nor do you need to create a test database or user. See "TRAITS" for more.

• fail_on_schema_break — makes the test run fail when the schema can not be created. Normally the test run is skipped when the schema fails to create. A failure can be more convenient when you want to spot compilation failures. 💀

Please note that although all initialization options can be set inlined or in a configuration file, some options can also be set via %ENV variables. %ENV settings will only apply IF there are no existing values for the option in any configuration file. As of this time we don’t merge %ENV settings, they only provide overrides to the default settings. Example use (assumes you’re using the default SQLite database):

DBNAME=test.db KEEP_DB=1 prove -lv t/schema/check-person.t

After running the test there will be a new file called 'test.db' in the home directory of your distribution. You can use:

sqlite3 test.db

to open and view the tables and their data as loaded by any fixtures or create statements. See Test::DBIx::Class::SchemaManager::Trait::SQLite for more. Note that you can specify both 'dbpath' and 'keep_db' in your configuration files if you prefer. I tried to expose a subset of configuration to %ENV that I thought was the most useful. Patches and suggestions welcomed. 🫶

---

✨ Initialization Sources ✨

The @sources are a list of result sources that you want helper methods injected into your test script namespace. This is the 'Source' part of:

$schema->resultset('Source');

Injecting methods are optional since you can also use the 'ResultSet' keyword. ✨

Imported Source keywords use Sub::Exporter so you have quite a few options for controlling how the keywords are imported. For example:

use Test::DBIx::Class
  'Person',
  'Person::Employee' => {-as => 'Employee'},
  'Person' => {search => {age=>{'>'=>55}}, -as => 'OlderPerson'};

This would import three local keyword methods, "Person", "Employee" and "OlderPerson". For "OlderPerson", the search parameter would automatically be resolved via $resultset->search and the correct resultset returned. You may wish to preconfigure all your test result set cases in one go at the top of your test script as a way to promote reusability. 💅

In addition to the 'search' parameter, there is also an 'exec' parameter which lets you process your resultset programmatically. For example:

'Person' => {exec => sub { shift->older_than(55) }, -as => 'OlderPerson'};

This code reference gets passed the resultset object. So you can use any method on $resultset. For example:

'Person' => {exec => sub { shift->find('john') }, -as => 'John'};

is_result John;
is John->name, 'John Napiorkowski', "Got Correct Name";

Although since fixtures will not yet be installed, the above is probably not going to be a normally working example :) 😭

Additionally, since you can also initialize sources via the 'resultsets' configuration option, which can be placed into your global configuration files, this means you can predefine and reuse resultsets across all your tests. Here is an example 't/etc/schema.pl' file where I initialize pretty much everything in one file:

 {
  'schema_class' => 'Test::DBIx::Class::Example::Schema',
  'resultsets' => [
    'Person',
    'Job',
    'Person' => { '-as' => 'NotTeenager', search => {age=>{'>'=>18}}},
  ],
  'fixture_sets' => {
    'basic' => [
      'Person' => [
        [
          'name',
          'age',
          'email'
        ],
        [
          'John',
          '40',
          'john@nowehere.com'
        ],
        [
          'Vincent',
          '15',
          'vincent@home.com'
        ],
        [
          'Vanessa',
          '35',
          'vanessa@school.com'
        ]
      ]
    ]
  },
};

In this case you can literally just do use Test::DBIx::Class and everything will happen automatically. ✨

In the example 't/etc/schema.pl' file, instead of (or as well as) fixture_sets you could instead define fixture_path to allow resultset data outside of the main 't/etc/schema.pl' file. 🦋

'fixture_path' => [qw{t etc fixtures}],

Create the file './t/etc/fixtures/basic.pl' and insert:

[
  'Person' => [
    [
      'name',
      'age',
      'email'
    ],
    [
      'John',
      '40',
      'john@nowehere.com'
    ],
    [
      'Vincent',
      '15',
      'vincent@home.com'
    ],
    [
      'Vanessa',
      '35',
      'vanessa@school.com'
    ]
  ]
]

Additional rulesets should be included within the outermost [ ] like this.

[
  'Person' => [
    ...
  ],
  'Job' => [
    ...
  ]
]

The 'basic' fixture would be used with fixtures_ok in exactly the same way as when it was embedded within schema.pl using fixture_sets. 💖

🌈 CONFIGURATION BY FILE 🌈

okay so by default we go looking for your config files in these spots, no asking first 💅

./t/etc/schema.*
./t/etc/[test file path].*

where . is the root of the distribution (the main character of your repo 🏠) and * is literally any of the configuration file types that the Config::Any configuration loader supports. so you can store your config in whatever format your heart desires, bestie, we're not gonna gatekeep 🎀

[test file path] is the relative path part under the t directory of the calling test script. like, if your test script is t/mytest.t, we add the path ./t/etc/mytest.* to the path. fr fr.

on top of that, we do a merge using Hash::Merge of all the matching configurations we found. this is the slay part — it lets you do 'cascading' configuration, going from the most global settings all the way down to the most local ones. it's giving layered outfit but for config ✨

you can override this whole search path with the -config_path key in options. so like, this one searches for t/etc/myconfig.* (or whatever the correct directory separator is for your operating system, we're inclusive here 🫶):

use Test::DBIx::Class -config_path => [qw/t etc myconfig/];

relative paths are rooted to the distribution home directory (aka the one that contains your lib and t directories). full paths get searched without any modification, periodt.

and yes you can specify multiple paths. this next one would search for both schema.* and share/schema:

use Test::DBIx::Class -config_path => [[qw/share schema/], [qw/schema/]];

lastly — and this is lowkey the cutest feature — you can use the special symbol + to say that your custom path adds to or prepends to the default search path. and since, as we said, we merge all the configurations we find, that means it's super easy to mix user level config settings with global settings, like:

use Test::DBIx::Class
    -config_path => [
        [qw(/ etc myapp test-schema)],
        '+',
        [qw(~ etc test-schema)],
    ];

which would search and combine /etc/myapp/test-schema.*, ./t/etc/schema.*, ./etc/[test script name].* and ~/etc/test-schema.*. so you get server level global settings, distribution level settings, and finally user level settings all stacked together. it's giving main character energy for your config stack 👑

pls note that in all the examples given, paths are written as an array reference of path parts, not as a string with delimiters (i.e. we do [qw(t etc)] rather than "t/etc"). this is not required, but it is recommended. every argument, string or array reference, gets passed to Path::Class so we can maintain better compatibility with non unix filesystems. if you are writing for CPAN, please consider our non Unix filesystem friends :) 💖

lastly (for real this time), there is a %ENV variable named TEST_DBIC_CONFIG_SUFFIX which, if it exists, can be used to further customize your configuration path. if we find that $ENV{TEST_DBIC_CONFIG_SUFFIX} is set, we attempt to find configuration files with the suffix appended to each of the items in the config_path option. so if you have:

use Test::DBIx::Class
    -config_path => [
        [qw(/ etc myapp test-schema)],
        '+',
        [qw(~ etc test-schema)],
    ];

and $ENV{TEST_DBIC_CONFIG_SUFFIX} = '-mysql', we will check the following paths for valid and loading configuration files (assuming unix filesystem conventions, bestie):

/etc/myapp/test-schema.*
/etc/myapp/test-schema-mysql.*
./t/etc/schema.*
./t/etc/schema-mysql.*
./etc/[test script name].*
./etc/[test script name]-mysql.*
~/etc/test-schema.*
~/etc/test-schema-mysql.*

each path is tested in turn and all found configurations are merged from top to bottom. this feature exists to make it easier to switch between sets of configuration files while you're developing. for example, you can create a test suite intended for a MySQL database, but allow a failback to the default Sqlite should certain enviroment variables not exist. iconic behavior honestly 🌸

---

💫 CONFIGURATION SUBSTITUTIONS 💫

similarly to Catalyst::Plugin::ConfigLoader, there are some macro style keyword inflators available for use inside your configuration files. this lets you set the value of a configuration setting from an external source, like from %ENV. there are currently two macro substitutions:

• ENV — given a value in %ENV, substitute the keyword for the value of the named substitution. for example, if you had:

email = 'vanessa__ENV(TEST_DBIC_LAST_NAME)__@school.com'

in your configuration file, then you could:

TEST_DBIC_LAST_NAME=_lee prove -lv t/schema-your-test.t

and then:

is $vanessa->email, 'vanessa_lee@school.com', 'Got expected email';

you might find this useful for configuring localized username and passwords, although personally I'd rather set that via configuration in the user home directory. (and yes the docs say two macro substitutions and then only list ENV — not me pointing that out 🙈 iykyk, we report faithfully here.)

---

🦋 TRAITS 🦋

as described, a trait is a Moose::Role that gets applied to the class managing your database and test instance. traits are installed by the 'traits' configuration option, which expects an ArrayRef as its input (however it will also normalize a scalar to an ArrayRef, we're flexible like that 💅).

available traits are as follows, bestie:

🐚 SQLite

this is the default trait, which will be loaded if no other traits are installed and there is no 'connect_info' in the configuration. in that case we assume you want us to go and create a tempory SQLite database for testing. please see Test::DBIx::Class::SchemaManager::Trait::SQLite for more. 🎀

🐬 Testmysqld

if MySQL is installed on the testing machine, and DBD::mysql too, we try to auto create an instance of MySQL and deploy our tests to that. similarly to the way the SQLite trait works, we attempt to create the database without requiring any other user effort or setup. zero notes, we just do it ✨

see Test::DBIx::Class::SchemaManager::Trait::Testmysqld for more.

🐘 Testpostgresql

if Postgresql is installed on the testing machine, along with DBD::Pg, we try to auto create an instance of Postgresql in a testing area and deploy our tests and fixtures to it. obsessed 🔥

see Test::DBIx::Class::SchemaManager::Trait::Testpostgresql for more.

---

👀 SEE ALSO 👀

the following modules or resources may be of interest.

DBIx::Class, DBIx::Class::Schema::PopulateMore, DBIx::Class::Fixtures

---

👑 AUTHOR 👑

John Napiorkowski C<< <jjnapiork@cpan.org> >>

---

🫶 CONTRIBUTORS 🫶

Tristan Pratt
Tomas Doran C<< <bobtfish@bobtfish.net> >>
Kyle Hasselbacher C<< kyleha@gmail.com >>
cvince
colinnewell
rbuels
wlk
yanick
hippich
lecstor
bphillips
abraxxa
oalders
felliott
Vadim Pushtaev C<< <pushtaev@cpan.org> >>
simonamor

look at this list 😭 literal legends, every single one of them 💜

---

💖 COPYRIGHT & LICENSE 💖

Copyright 2012, John Napiorkowski "<jjnapiork@cpan.org>"

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

---

and that's the whole page, bestie, you made it to the end 🏁✨ this little beauty is from perl v5.36.0, dated 2023-01-29, brought to you by the Test::...::Class(3pm) manual page. go forth and test your database stuff with confidence, you absolute icon 👑💅🦋