Organising your test cases
In many modules different test cases will need to run in different contexts. For example, one set of tests might need test data inserted into the database; another might need the module's tables created but to bypass the module's _install function.
DrupalWebTestCase and DrupalUnitTestCase can be extended to handle these scenarios and you can see this sort of approach at work in modules/simpletest/tests/database_test.test
Centralising the creation of sample data for tests
For consistency, and to save time, you can create all your sample data in a class, and let your test cases inherit it.
<?php
class MyModuleWebTestCase extends DrupalWebTestCase {
function setUp() {
parent::setUp('mymodule');
// Insert your data into the database here
// Use db_insert() etc. Hard coded SQL will affact your actual drupal installation, not your test environment
}
}
class MyModuleExampleTestCase extends MyModuleWebTestCase {
// No setUp() function necessary, because the setUp is inherited
public static function getInfo() {
...
}
function testExample() {
// Your test(s) here
}
}
?>Testing the database without the overhead of installing your module
Tests that do not need any database functionality simply extend DrupalUnitTestCase, but if you wish you test your module's interaction with the database without enabling the whole module, you can use drupal_install_schema() to make the necessary tables.
<?php
class MyModuleDatabaseTestCase extends DrupalWebTestCase {
function setUp() {
// Create the module's tables without running hook_install or hook_enable
drupal_install_schema('mymodule');
}
}
class MyModuleSchemaTestCase extends MyModuleDatabaseTestCase {
// No setUp() function necessary, because the setUp is inherited
public static function getInfo() {
return array(
'name' => 'Database functions test',
'description' => 'Tests CRUD functions',
'group' => 'My Module',
);
}
/*
* Tests that parent class created module tables
*/
function testSchemaCreated() {
// Your test(s) here
}
}
?>