Currently it doesn't seem like there's any way of running kernel tests in a multisite setup, where a module is within a site's directory.

Where a module exists at drupal_root/sites/sitename/modules/custom/my_module, it doesn't seem possible to run PHPUnit kernel tests for any tests within that module. (I'd assume functional tests too, but I can't get those working on my machine right now :D)

The problem comes right at the start during setup: 

public static $modules = ['my_module'];

It seems that this is because Simpletest installs itself in a new site directory, eg drupal_root/sites/simpletest/, it doesn't have access to the modules in the other directory. As far as I can tell the only directories it scans are drupal_root/core, drupal_root/sites/all, drupal_root and drupal_root/sites/simpletest/###

This was while running the tests directly, eg $ phpunit drupal_root/sites/sitename/modules/custom/my_module/tests/src/NameOfTest.php, so it wasn't an automated discovery/testsuite issue.

If there is a way of running PHPUnit tests within a multisite installation then it doesn't seem to be documented anywhere. This seems like a pretty major omission.

Would it be possible for example to pass in a "site" paramater to the PHPUnit command, so that it runs within a particular site directory? Or allow discovery of modules from other directories?

Comments

Sophie.SK created an issue. See original summary.

joachim’s picture

joachim commented

> Would it be possible for example to pass in a "site" paramater to the PHPUnit command, so that it runs within a particular site directory?

Given that the test class knows it's testing this module in sites/sitename/modules/custom/my_module, this should be something the test class code can specify.

That way the developer doesn't have to worry about it when running tests from the command line, and is saved the repetition.

Though:

> Or allow discovery of modules from other directories?

This seems like the better option to me. I happened to poke around at at \Drupal::service('extension.list.module') this morning, and that is aware of modules in all site directories.

cilefen’s picture

cilefen commented
Related issues: +#2985199: Extensions in Multisite Directories Not Registered When Rebuilding Cache

This reminds me a little of another issue.

sophie.sk’s picture

sophie.sk
she/her
Primary language English
commented

@cilefen - yes, I spent today trying to get that patch installed, only to realise we actually already had that patch on the site, so it clearly hasn't helped :( I thought it might be related, though.

@joachim - I'm not sure which would be more useful. Discovery of modules would be good for groups (eg $ phpunit --group=my_modules_that_span_across_different_sites), but mimicking a Drupal install by passing in a site parameter would also be handy (because site_one doesn't and shouldn't have access to the modules in site_two).

Why not do both then?! Open source devs don't have enough to do already :D

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

super_romeo’s picture

super_romeo commented
Related issues: +#3224618: Extensions within multisite setups not exists while testing
super_romeo’s picture

super_romeo commented

Workaround:

protected function setUpFilesystem() {
    parent::setUpFilesystem();
    $this->setSetting('test_parent_site', 'sites/my_site');
  }

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

tunprog’s picture

tunprog
Primary language English
Location Paris 🇫🇷
commented

@super_romeo Thank you but it didn't work for me.

I changed the location of the module temporarily just to finish writing tests then I will get back to this later.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

kevinquillen’s picture

kevinquillen commented

As a workaround, for Kernel tests, you can do this:

  /**
   * {@inheritdoc}
   */
  protected function setUpFilesystem(): void {
    parent::setUpFilesystem();
    $this->setSetting('test_parent_site', 'sites/SITENAME');
  }

for Functional tests:

  /**
   * {@inheritdoc}
   */
  protected function prepareSettings() {
    parent::prepareSettings();
    $directory = DRUPAL_ROOT . '/' . $this->siteDirectory;
    $append = '$settings["test_parent_site"] = "sites/SITENAME";';
    file_put_contents($directory . '/settings.php', $append, FILE_APPEND | LOCK_EX);
  }

this worked for me to get my tests moving.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.