I'm a bit confused about best practices for testing in Drupal 7.

When I'm going to deploy, should I run the entire test suite—including all Drupal core tests—every time? This seems like a bit of overkill, especially given how long each test takes to run.

At the same time, it seems logical that I should run all tests every time, since code changes I make in my custom modules could break something in core (via hooks, etc.). The problem is, each test runs in a sandbox with only its dependencies enabled, so core tests won't even be aware of my custom modules and thus won't fail even if they should.

I'm accustomed to testing in Rails, in which tests are run against the entire application as a cohesive unit, with all "modules" (gems) being enabled at test runtime. It seems that in Drupal, only certain pieces are tested at a time, which prevents an accurate assessment of whether the site will work in production.

So I guess my question is twofold: A) Should I run the entire Drupal test suite (including core tests) every time I deploy? B) How do I check whether my custom code causes core tests to fail, given that core tests don't take custom modules into account?

1 Answer 1


No, running Drupal core test suite is wrong. You can assume that your code won't messed up drupal core and if you so - you'll get exception for that and then the fun will start :).

If you came from the ruby world then you probably familiar with the Behat solution and if not you should check this - very easy to use QA platform and a lot of posts were written in order to test your site with behat. But there is also selenium that can help you.

And i'll give a you a tip on how to start the testing suite for your site: For now you probably have a running site. You need to take a pen and paper or a google doc and start what features you create for your site: what happens when the use login, what happens when he create node. After you wrote your tests you can start to write them in test - behat, selenium simple test... what ever! As long as those tests testing your features.

Another tip is: when ever you have a bug and you fixed this, you write a test that verity that the bug can't be reproduced. This the way all of the big projects i know works: OG, Message stack, Open scholar,

  • Thanks! We currently have an RSpec/Capybara integration test suite for our site, but I had thought it'd make sense to convert it to native Drupal testing. So, SimpleTest is really more for unit test and for testing patches against, then? Dec 19, 2013 at 2:20
  • You can write your test suite with simpletest but it won't be simple. It's because simple build the database from scratch and you need to enable your modules and features and settings and you need to do that programaticlly. Instead, when using a behat/selenium against a development environment with the latest DB the the tests are more faster and easier. I would recommend on behat. For now, this the QA platform were using but any BDD solution would be great.
    – Roy Segall
    Dec 19, 2013 at 7:23
  • Sure, but again, what is the purpose of having SimpleTest, then? Dec 20, 2013 at 21:16
  • I think the only reason is exists is for the module development. People want to test their site easily. Now we have JS as integrated part and simple test is not the tool for that.
    – Roy Segall
    Dec 21, 2013 at 9:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.