++ed by:

1 non-PAUSE user.

Geoff Richards


Daizu::Test - functions for use by the test suite


The functions defined in here are only really useful for testing Daizu CMS. This stuff is used by the test suite, in particular t/00setup.t which creates a test database and repository.



Name of configuration file which provides information about how to connect to the databases used for the test suite. The test_config function parses this.

Value: test.conf


Name of the SQL file containing the database schema to load into the test database after creating it.

Value: db.sql


Full path to the directory which should contain the testing repository created at the start of running the tests.

Value: .test-repos in the current directory


A 'file' URL to the test repository.


Full path to the Subversion dump file which is loaded into the test repository.

Value: test-repos.dump in the current directory.


Full path to the directory into which output from publishing test content should be written.

Value: .test-docroot in the current directory


Filename of config file to use for testing.

Value: test-config.xml (which is created from test-config.xml.tmpl by t/00setup.t)


The following functions are available for export from this module. None of them are exported by default.

init_tests($num_tests, [$show_errors])

Load the test configuration file (which will allow you to use the test_config() function later), and check it to make sure the tests are properly configured. If they are then initialize Test::More with the number of tests expected (unless $num_tests is undef). Otherwise tell Test::More to skip all the tests.

If $show_errors is present and true, display warnings about any problems with the test configuration file. This should be done in the first test program so that the user knows why the tests aren't being run. The others can just skip the tests.


Return a reference to a hash of configuration values from the file specified by $TEST_DBCONF_FILENAME. This will fail if init_tests() hasn't been run yet.


Returns a DBI database handle connected to the PostgreSQL template1 database, which can be used for example to create the test database.


Create the test database, load the database schema into it, and return a DBI handle for accessing it.


Delete the test database. Sleeps for a second before doing so, to give the connections a chance to really get cleaned up.


Create an empty Subversion repository for testing, in $TEST_REPOS_DIR.


Return the navigation menu for $file, by calling the navigation_menu method on its generator. The result is returned after some basic checks have been made that it is properly structured. Any problems will cause an assertion to fail (even if DEBUG isn't set).

test_menu_item($item, $desc, $num_children, $url, $title, [$short_title])

Run tests (using Test::More) on the navigation menu item provided in $item (which should be a hash of the type returned for each item by the navigation_menu method of generator classes).

$desc should be a short piece of text to use in the names of the tests. $num_children is the number of children expected to be present in it (although they aren't checked, only the number of them is). $url is a string representation of the expected URL, which is likely to be a relative URL. $title and $short_title are the expected 'title' and 'short_title' values, which may be undef if those values are expected to be missing. If $short_title isn't supplied (the argument is missing rather than undefined) then that won't be tested at all.

The tests will be skipped with an appropriate warning if $item is undefined.

test_cmp_guids($db, $wc_id, $desc, $got, @expected)

Compare the array of GUID IDs referenced by $got with the GUID IDs of the filenames listed in @expected. The order doesn't matter. $desc is a string to put in the test descriptions.

$got may contain other GUID IDs which aren't expected, so you should check that you've got the right number as well as calling this.

test_cmp_urls($desc, $got, @expected)

Compare the URLs in the array referenced by $got with the ones listed in @expected. In both cases they can be plain strings or URI objects. The order they are given in doesn't matter.

There must be at least one URL expected, and the number of ones in the two arrays is compared in the first test.


This software is copyright 2006 Geoff Richards <geoff@laxan.com>. For licensing information see this page: