Use a separate test database, transactional/rollback and easily load fixtures for test case data

I really love this idea. If your tests are buggy, it's possible to totally fubar your database. :P And while there is a very clear sentence in the README that says NOT to use this on a production database, we all know how many people read READMEs. :P

Maybe we could include this into http://drupal.org/node/210679 .

This sounds like something that could be useful for SimpleTest. If so we need to affirm it as a community and update this patch.

Here's a snippet (untested, but something pretty similar is working for another project) that will install a profile.

  // Create test database. Probably error-handle this so if it fails, resort to table prefixes instead.
  db_query("CREATE DATABASE simpletest_". $this->randomName());

  // Modify $db_url so you can connect to two databases.
  global $db_url;
  $db_url['default'] = $db_url;
  // Parse out db username password etc.
  $db_url['test'] = $test_db_url;
  db_set_active('test');

  // Install a given profile.
  include_once './includes/install.inc';
  drupal_install_system();
  $module_list = drupal_verify_profile($profile, 'en');
  drupal_install_modules($module_list);

  // Do any preliminary stuff; setup content types, set variables, etc.


  // Run the tests.

  // Return to Drupal.
  db_set_active();

Note that we want to use a prefix like simpletest_abcdefqw , aka randomname(8) so that if simpletest dies on us then we won't get a lot of angry MySQL errors the next run. Using a prefix makes it simpler, a separate database would be complicated for the users.

This is easy stuff for Drush. I will add it to the new simpletest runner. But which profile to use?

This could be slower than just running a mysql statement to load up a DB but we'll try this first.

Oops - I have to port Drush to D6. I'll do that real soon now.

the profile you are running right now, it's available from settings.php isn't it? if not, then default or provide an admin ui.

This is going to be somewhat tricky as you need to edit settings.php for subsequent Drupal boots to keep the new (random) prefix and then, when simpletest is done, we need to make sure it gets reset -- which is tricky if simpletest dies (can happen, we are testing). I think I will set CURLOPT_USERAGENT to "simpletest $db_prefix" and getting the handling of this written to settings.php at form time and adding something which indicates it's there. Something like:

if (substr($_SERVER['USER_AGENT'], 0, 11) == 'simpletest ')) {
  $db_prefix = preg_replace('/[^A-Za-z0-9]/', '', substr($_SERVER['USER_AGENT'], 11));
}
$GLOBALS['simpletest_ua_handling'] = TRUE;

should go to settings.php.

Beware, this patch litters your database as there is no cleanup. Also it does not work -- but why? Add

if (substr($_SERVER['HTTP_USER_AGENT'], 0, 11) == 'simpletest ') {
  $db_prefix = preg_replace('/[^A-Za-z0-9]/', '', substr($_SERVER['HTTP_USER_AGENT'], 11));
}
$GLOBALS['simpletest_ua_handling'] = TRUE;

to settings.php

Edit: "Does not work" mean, the user created (always uid 3) does not get its roles. I still have to figure out why.

Here we go. I have added a few more lines of code from install.php and made sure the useragent-based prefix is safe. It seems working.

Oh, and the settings.php part:

if (preg_match('/simpletest\d+/', $_SERVER['HTTP_USER_AGENT'])) {
  $db_prefix = $_SERVER['HTTP_USER_AGENT'];
}
$GLOBALS['simpletest_ua_handling'] = TRUE;

we obviously need to work on code to make sure it's there.

Reroll.

Another reroll against HEAD. Also, this adds a safeguard before dropping tables.

Looks great. Very nice first step.

The way you use the useragent to pass the db_prefix to allow for multiple different test sessions was very clever.

Per test.

Now with bonus whining.

This appears to work great.

This patch means that the db will be flushed after each test method is called. Which is exactly what we have been needing.

This patch also works for multiple testing sessions running simultaneously.

Great work chx!

Note: leaving this for further testing, review, and comments.

Patch works tables are created, used and removed after every test case. I have 2 problems with this patch:
1) page node creation tests I tried don't finish successfully probably this is the reason. I get this "Sorry, unrecognized username or password. Have you forgotten your password?" right after attempt to login simpletest user
2) building and destroying new tables before and after every 2 line unit test might be a bit of an overkill not sure what we can do about it.

I've read through the patch and it looks GREAT.
+(500⁵⁰⁰)

looks good, but haven't actually tested it yet.

Also, is there any security concern with this USER_AGENT method? What happens if I access a site remotely with a browser where I can set HTTP_USER_AGENT- can I get Drupal to run a new install with prefixed tables?

@pwolanin: Good point. I know you can get an extension to do that in Firefox and I believe Konqueror lets you do it by default.

Probably need to generate some sort of key when SimpleTest is installed then pass that along with db_prefix to ensure it is coming from SimpleTest.

@Rok Žlender: Yea that could be an issue. One thought I had was make a different test case that unit tests extend since allot of the DrupalTestCase functionality is for function browser based tests.

If we create a new test case that could fix the issue.

@boombatower - one suggestion for a key that can be checked in settings.php: pass (in the query string?) the hash of the drupal private key with the simpletest prefix. Or alternately (since I guess this is all running before bootstrap) on install write such a key private key into settings.php?

This patch require a key to set the prefix in settings.php.

This will prevent the situation which pwolanin described.

I have tested and seems to work.

@boombatower - something doesn't look right about that code - you are going to set $GLOBALS["simpletest_ua_key"] every time settings.php is parsed?

@pwolanin: the key needs to be there when SimpleTest starts the chain...which we have no way of knowing before hand...and settings.php must have same key so it needs to be there.

Limits to that yes.

Committed.

I ci a small patch that fixes problems with clean urls. http://drupal.org/cvs?commit=107508