DESCRIPTION

Takes care of setting up a Test::Mojo with the Conch application pre-configured.

Includes JSON validation ability.

my $t = Test::Conch->new;
$t->get_ok('/')->status_is(200)->json_schema_is('Whatever');

CONSTANTS

METHODS

pg

Override with your own Test::PostgreSQL object if you want to use a custom database, perhaps with extra settings or loaded with additional data.

This is the attribute to copy if you want multiple Test::Conch objects to be able to talk to the same database.

validator

fixtures

Provides access to the fixtures defined in Test::Conch::Fixtures. See “load_fixture”.

new

Constructor. Takes the following arguments:

* pg (optional). uses this as the postgres db.
  Otherwise, an empty database is created, using the schema in sql/schema.sql.

* config (optional). adds the provided configuration data.

init_db

Sets up the database for testing, using the final schema rather than running migrations. Mirrors functionality in “initialize_db” in Conch::DB::Util. No data is added – you must load all desired fixtures.

Note that the Test::PostgreSQL object must stay in scope for the duration of your tests. Returns the Conch::DB object as well when called in list context.

ro_schema

Returns a read-only connection to an existing Test::PostgreSQL instance.

status_is

Wrapper around “status_is” in Test::Mojo, adding some additional checks.

* successful GET requests should not return 201, 202 (ideally just 200, 204).
* successful DELETE requests should not return 201
* 200 requests should have content.
* 201 and most 30x requests should have a Location header.
* 204 requests should not have content.

Also, unexpected responses will dump the response payload.

location_is

Stolen from Test::Mojo’s examples. I don’t know why this isn’t just part of the interface!

location_like

As “location_is”, but takes a regular expression.

json_schema_is

Adds a method ‘json_schema_is` to validate the JSON response of the most recent request. If given a string, looks up the schema in #/definitions in the JSON Schema spec to validate. If given a hash, uses the hash as the schema to validate.

json_cmp_deeply

Like “json_is” in Test::Mojo, but uses “cmp_deeply” in Test::Deep for the comparison instead of “is_deep” in Test::More. This allows for more flexibility in how we test various parts of the data.

load_validation_plans

Takes an array ref of structured hash refs and creates a validation plan (if it doesn’t exist) and adds specified validation plans for each of the structured hashes.

Each hash has the structure:

{
    name        => 'Validation plan name',
    description => 'Validation plan description',
    validations => [
        'Conch::Validation::Foo',
        'Conch::Validation::Bar',
    ]
}

If a validation plan by the name already exists, all associations to validations are dropped before the specified validations are added. This allows modifying the membership of the validation plans.

Returns the list of validations plan objects.

load_validation

Add data for a validator module to the database, if it does not already exist.

load_fixture

Populate the database with one or more fixtures. Returns the objects that were explicitly requested.

reload_fixture

Loads the fixture again. Will die if it already exists (you should use “load_fixture” unless you are sure it has since been deleted).

add_fixture

Add one or more fixture definition(s), and populate the database with it.

load_fixture_set

Generates a set of fixtures by name and optional arguments, then loads them into the database. See “generate_set” in Test::Conch::Fixtures for available sets.

generate_fixtures

Generate fixture definition(s) using generic data, and any necessary dependencies, and populate the database with them.

Not-nullable fields are filled in with sensible defaults, but all may be overridden.

e.g.:

$t->generate_fixture_definitions(
    device_location => { rack_unit => 3 },
    rack_layouts => [
        { rack_unit_start => 1 },
        { rack_unit_start => 2 },
        { rack_unit_start => 3 },
    ],
);

See “_generate_definition” in Test::Conch::Fixtures for the list of recognized types.

authenticate

Authenticates a user in the current test instance. Uses default credentials if not provided. Optionally will bail out of *all* tests on failure. This will set ‘user’ in the session ($t->app->session('user')).

txn_local

Given a subref, execute the code inside a transaction that is rolled back at the end. Useful for testing with mutated data that should not affect other tests. The subref is called as a subtest and is invoked with the test object as well as any additional provided arguments.

email_cmp_deeply

Wrapper around “cmp_deeply” in Test::Deep to test the email(s) that were “sent”. $got should contain a hashref, or an arrayref of hashrefs, containing the headers and content of the message(s), allowing you to test any portion of these that you like using cmp_deeply constructs.

$t->email_cmp_deeply({
    To => '"Foo" <foo@conch.us>',
    From => '"Admin' <admin@conch.us>',
    Subject => 'About your new account',
    body => re(qr/^An account has been created for you.*Username:\s+foo.*Email:\s+foo@conch.us\s+Password:/ms),
});

A default ‘From’ header corresponding to the main test user is added as a default to your $expected messages if you don’t provide one.

Remember: “Line endings in the body will normalized to CRLF.” (see “create” in Email::Simple)

email_not_sent

Tests that *no* email was sent as a result of the last request.

log_is

Searches the log lines emitted for the last request for one with the provided message, which can be either an exact string or anything that Test::Deep recognizes.

If you are expecting a list of message strings (sent at once to the logger), pass a listref rather than a list.

A log line at any level matches, or you can use a more specific method that matches only one specific log level:

log_debug_is

log_info_is

log_warn_is

log_error_is

log_fatal_is

add_routes

Convenience method to add additional route(s) to the application, without breaking the routes that are already in a specific order.

$routes should be a Mojolicious::Routes object that holds the route(s) to be added.

LICENSING

Copyright Joyent, Inc.

This Source Code Form is subject to the terms of the Mozilla Public License, v.2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.