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_configfunction parses this.
Name of the SQL file containing the database schema to load into the test database after creating it.
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_testsis undef). Otherwise tell Test::More to skip all the tests.
$show_errorsis 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.
Returns a DBI database handle connected to the PostgreSQL
template1database, 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
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
$descshould be a short piece of text to use in the names of the tests.
$num_childrenis the number of children expected to be present in it (although they aren't checked, only the number of them is).
$urlis a string representation of the expected URL, which is likely to be a relative URL.
$short_titleare the expected 'title' and 'short_title' values, which may be undef if those values are expected to be missing. If
$short_titleisn'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
- test_cmp_guids($db, $wc_id, $desc, $got, @expected)
Compare the array of GUID IDs referenced by
$gotwith the GUID IDs of the filenames listed in
@expected. The order doesn't matter.
$descis a string to put in the test descriptions.
$gotmay 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
$gotwith 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 <email@example.com>. For licensing information see this page: