I have a site deployment module, which, when enabled on my site, enables all the modules we need; this is useful with dummy data for testing and development so we don't need to clone the production database.

On one of my sites, one of the dependencies of my site deployment module is Simple LDAP's simple_ldap_user module, which breaks some of the functionality if the LDAP server is not configured. My solution is to disable simple_ldap_user when running my automated tests, so I end up with a test which looks like this:

class MyTest extends DrupalWebTestCase {
  public function setUp($modules = array()) {
    parent::setUp('my_site_deployment_module');
    // node_access_rebuild required by access control module
    node_access_rebuild();
    // FALSE because I don't want the site deployment module to be disabled as
    // well
    module_disable(array('simple_ldap_user'), FALSE);
    $this->resetAll();
    $this->assertFalse(module_exists('simple_ldap_user'), 'Simple ldap user has been disabled correctly');
  }

  public function testCase() {
    ...

The assertion above passes in the GUI, but when I run this exact code on my continuous integration server on the command line, that same assertion systematically fails:

Test MyTest->setUp() failed: Simple ldap user has been     [error]
disabled correctly in /opt/jenkins/workspace/myproject

There must be some condition which prevents modules from being disabled in certain circumstances. I set this to a support request rather than a bug report because it's not something I tried to reproduce on a new site; nonetheless I'm documenting it here in case anyone else runs into a similar issue.

Comments

cilefen’s picture

Are you sure you want to pass FALSE as the second parameter to module_disable()? It seems like the disabling could fail if you do not allow it to disable the dependent modules.

alberto56’s picture

@cilefen, thanks for your response.

Actually, yes, because: simple_ldap_user is a dependency of the site deployment module which defines a bunch of stuff i don't want to disable. I am explicitly passing FALSE because I want to keep the site deployment module, but not simple_ldap_user, just in the context of the test.

cilefen’s picture

Does simple_ldap_user have any dependents?

alberto56’s picture

simple_ldap_user has no dependents other than the deployment module

my_site_deployment_module depends on simple_ldap_user
my_site_deployment_module depends on simple_ldap
(no other module depends on simple_ldap_user)
simple_ldap_user depends on simple_ldap

The behaviour I am expecting when calling module_disable(array('simple_ldap_user'), FALSE); is for simple_ldap_user to be disabled, but not my_site_deployment_module which is its dependent.

This is in fact what happens, but not on all environments.

cilefen’s picture

@alberto56 If I understand right, to disable simple_ldap_user would leave my_site_deployment_module without one of its dependencies. Is that really what you want?

Are the versions of PHP the same in these environments? What command are you using to execute the test?

alberto56’s picture

Status: Active » Closed (cannot reproduce)

In both cases I'm using PHP 5.3 on CentOS 6. The command on the command line is drush test-run my-test-group and I'm using drush 6.5.0.

Also, confirming that just for testing, I actually want to leave my_site_deployment_module enabled, but without one of its dependencies. I know it is unusual, but I want simple_ldap_user to be a dependency of my_site_deployment_module because when someone installs that site, it is done by enabling my_site_deployment_module, and in that case I want simple_ldap_user to be enabled as well. However, during testing, simple_ldap_user causes issues because it's not configured, so I want to disable it, knowing that it won't break the rest of the site.

That approach is probably wrong, come to think of it, because I'm testing the site in a state that is unlike production. I ended up removing simple_ldap_user as a dependency of my_site_deployment_module.

It is still bizarre to me that module_disable() would be fail to disable a module without throwing a warning. I'll set to "cannot reproduce" for now, unless someone else is having the same problem.

Thanks for your time @cilefen!

alberto56’s picture

Title: In a simpletest module_disable() sometimes does not disable modules » In a simpletest module_disable(array(...), FALSE) sometimes does not disable modules