Test-driven Drupal development, take 2

A while ago I wrote about a method we'd been using internally here at OpenSourcery for testing existing Drupal configurations. There are currently a few issues in the works that would get this functionality into core-SimpleTest:

In the meantime, however, since this functionality has immediate benefits to making more robust Drupal sites, I've decided to release the module we're using internally until this is part of core-SimpleTest, and gets back-ported to Drupal 6.x. I've placed the module on GitHub rather than on Drupal.org so as not to clog things up with placeholder modules. I've also attached a tar-ball to this post for those without Git.

Update: This module has also been released on Drupal.org in order to allow people to track updates.

To use the module, it must be enabled, and then included at the top of any test file that extend the class:

// Include SimpleTest Clone
module_load_include('test', 'simpletest_clone');

tests then extend the SimpleTestCloneTestCase class instead of DrupalWebTestCase:
class CustomTestCase extends SimpleTestCloneTestCase {
...
}

Occasionally, on a given site or set of tests, it may not be desirable to clone every table because this can make tests run for a very long time. Because of this, there is a method in place for excluding tables from being cloned:

  /**
   * When testing data-intensive sites, if the tests will still run correctly,
   * tables can be excluded here. The structure will still be cloned, but the
   * data will not be copied over.
   */
  function __construct($testId = NULL) {
    parent::__construct($testId);
    $this->excludeTables = array(
      // List of tables to exclude goes here.
      'example_table_foo',
      'example_table_bar',
    );
  }

AttachmentSize
simpletest_clone.tar_.gz2.9 KB

Tagged as: Drupal, SimpleTest, Test-driven development

7 comments

Michael Schwern wrote 2 years 37 weeks ago

github downloads

Awesome! I didn't know about excludeTables. Perhaps we should include some sensible defaults like watchdog and the cache tables?

For those without git, there's the little "download" button (which is Javascript and difficult to link to) which will give you a zip or tarball of the latest code. This is distinct from the "download" tab which will only give you archives of tagged releases (confusing, I'll nudge them about it). I'd suggest just tagging this release, putting up a link to the github downloads page and pulling the attached tarball off this post to avoid people getting some wildly out of date version.

Peter Vanhee (not verified) wrote 2 years 36 weeks ago

Why not release on drupal.org?

Thanks for the module! However, for us to install it, update it and so on, it will be much easier if the module was hosted on drupal.org. In my opinion, a placeholder module could perfectly live there as well.

drupal development (not verified) wrote 2 years 36 weeks ago

advertising

Its really very good.

Jonathan Hedstrom wrote 2 years 35 weeks ago

Released on d.o.

Peter,

For the reasons you mentioned above, this has been released on Drupal.org

http://drupal.org/project/simpletest_clone

balaji (not verified) wrote 2 years 29 weeks ago

hai, Thank you for your

hai,

Thank you for your contribution.It would be better if the module was hosted in drupal.org for easy access and utilization for the users.

Thanks
Balaji

william (not verified) wrote 2 years 15 weeks ago

his seems like a great idea

his seems like a great idea to me and it helps us slowly move into that phase without making a full, harsh, top-down commitment.

Lots of folks are blocked from contributing because of lack of knowledge - PHP, CVS, dedicated server, Issue Queues, English(!) - these prevent people from being able to help. Adding in the "must have a test" hurdle will keep even more people away.

Part of the solution will be specialists. Much like chx/pwolanin handle most menu bugs or eaton tends to do lots with node rendering and FAPI, or keith.smith tends to do a lot of string improvement, and catch does a million reviews, we need to get some folks who are really capable and speedy with developing tests so that they can get involved in a patch that looks great except for lacking a test. I think a transition period like you describe will help that.

I don't think this should run too long, though. Perhaps just for a few months and then we start making tests required for core.

Now, to go see about writing some simpletests for my contributed modules... ;)

Rich Yumul (not verified) wrote 1 year 15 weeks ago

THANKS

Just wanted to thank you in your effort in this area. This is exactly what I needed to keep on moving with my project.