I have a Drupal system using a legacy database, so I'm making calls to db_set_active('legacy') multiple times.

I want to create a webtest IE:

class MymoduleTestCase extends DrupalWebTestCase {

}

that enables my custom modules and tests it.

I'm trying to find out a few things about how simple test handles multiple database connections.

1. Will this test create a secondary copy of my 2nd database? Do I need to worry about testing data getting inserted/deleted from my database?
2. will I have to include installation details in my module's .install file? (schema, custom SQL inserts for data)
3a. Do I need to specially format my queries to the second database?
3b. Does testing rely on Drupal's db_query function and wrapping your tables in brackets "{tablename}"? (I've left out brackets on most of my legacy database queries since I don't use db_prefixing)

Anyone have any good links to discussions about this topic? I've tried searching google/drupal but nothing good was to be found.

Thanks All!

Comments

boombatower’s picture

boombatower commented
Assigned: Unassigned » boombatower
Status: Active » Postponed (maintainer needs more info)

Basically SimpleTest installs Drupal in a set of prefixed tables in the "default" database using the "default" profile.

Tests are then expected to add any test data and such.

I have never messed with an external legacy database like that, so you are in new territory. Assuming that you don't using the Drupal prefixing system, ie:

SELECT {table}

you should be good. If you use it then you will need to temporarily reset the global $db_prefix variable since SimpleTest changes it when running tests.

markDrupal’s picture

markDrupal commented
Status: Fixed » Postponed (maintainer needs more info)

Thanks, it looks like I can go about this in 2 ways.
1. ignore db prefixing and test using the live data in the secondary database, or
2. use db prefixing and make sure that the dbs can be recreated during the test by placing their schema into the install function of one of my modules. Additionally, make sure all db queries to the external databases use "{}" around the table names so they can be prefixed during the test run.

I chose option 2 because I saw a problem with option 1, which is during the tests data may be added to or deleted from the legacy database. And it's risky to run the tests on the live set of data.

I'll try using external databases with simpletests. But so far it looks like it will work fine.

UPDATE--
I notice that I cannot just assume my module gets uninstalled. the cleanup databases function does not properly remove tables created in my secondary database during the test. So to fix that I had to manually disable and uninstall my module in the tearDown() method. My dcats_uninstall() function uses the normal drupal_uninstall_schema('dcats') .

  public function tearDown() {
    //If you leave it to the parent class to disable this module
    //it will try to uninstall it from the primary database "drupal_dcats"
    module_disable(array('dcats'));
    dcats_uninstall();
    parent::tearDown();
  }

I use Foreign key constraints so it is essential that I disable them before trying to drop the tables, or it will fail. 

function dcats_uninstall() {
  db_set_active('dcats');
  db_query("SET FOREIGN_KEY_CHECKS=0");
  drupal_uninstall_schema('dcats');
  db_query("SET FOREIGN_KEY_CHECKS=1");
  db_set_active('default');
}
boombatower’s picture

boombatower commented
Status: Postponed (maintainer needs more info) » Fixed

I believe everything is fine then.

Please re-open if not.

Status: Postponed (maintainer needs more info) » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.