Contrib.social

Importing config in functional tests

Open on Drupal.org →
Created on 27 January 2016, almost 9 years ago
Updated 6 September 2024, 4 months ago

Our current project uses custom modules for which we write tests, and configuration that is exported and imported through drush cex and cim. As some of the custom code depends on configuration, we need to mimick drush cim when setting up our integration tests. For that, we use the following code:

class FooIntegrationTest extends BrowserTestBase {

  /**
   * {@inheritdoc}
   */
  protected function setUp() {
    parent::setUp();

    $site_uuid = 'some-uuid.....';
    $source_config_directory = './path/to/cmi/export';

    /** @var \Drupal\Core\Config\ConfigFactoryInterface $config_factory */
    $config_factory = $this->container->get('config.factory');
    $config_factory->getEditable('system.site')->set('uuid', $site_uuid)->save(TRUE);
    $source_storage = new FileStorage($source_config_directory);
    /** @var \Drupal\Core\Config\StorageInterface $active_storage */
    $active_storage = $this->container->get('config.storage');
    $config_comparer = new StorageComparer($source_storage, $active_storage, $this->container->get('config.manager'));
    $config_comparer->createChangelist();
    $config_importer = new ConfigImporter(
      $config_comparer,
      $this->container->get('event_dispatcher'),
      $this->container->get('config.manager'),
      $this->container->get('lock'),
      $this->container->get('config.typed'),
      $this->container->get('module_handler'),
      $this->container->get('module_installer'),
      $this->container->get('theme_handler'),
      $this->container->get('string_translation')
    );
    $config_importer->import();

    $this->setUpIntegration($this->container);
    $this->rebuildContainer();
  }

This basically imports our exported config into the current sandbox site, and then rebuilds the container, which should make any static caches irrelevant, as the services those caches belong to are not part of the rebuilt container.

This, however, does not work entirely. We're getting some yet unresolved DB exceptions are the semaphore table does not yet exist in one of _drupal_shutdown_function()'s callbacks.

Are we missing any obvious steps? How do other developers test their code that depends on CMI imports?

💬 Support request
Status

Closed: outdated

Version

11.0 🔥

Component
Configuration  →

Last updated about 17 hours ago

Created by

🇬🇧United Kingdom Xano Southampton

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇨🇦Canada Liam Morland Ontario, CA 🇨🇦

    I am trying to run functional tests with imported config. Based on the above, I have tried this:

      protected function setUp() : void {
    parent::setUp();

    // Import config, like `drush config:import`.
    $config_path = DRUPAL_ROOT . '/../config/sync';
    $config_source = new FileStorage($config_path);
    $this->container->set('config.storage.sync', $config_source);

    $config_factory = $this->container->get('config.factory');
    $site_uuid = 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX';
    $config_factory->getEditable('system.site')->set('uuid', $site_uuid)->save(TRUE);

    $this->configImporter()->import();
  }

    I get these errors:

    Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
    Cannot change the install profile from testing to standard once Drupal is installed.
    Unable to install the standard module since it does not exist.
    Unable to uninstall the Testing module because: The Testing module is required.
    Unable to uninstall the Testing profile since it is the install profile.

    Is there some way around this? I just want to simulate running drush config:import.

  • Status changed to Closed: works as designed 4 months ago
  • Comment 4 months ago →
    🇳🇿New Zealand quietone

    As explained in #14 the core issue queue is not the place for support requests.

    The Drupal Core issue queue is not the ideal place for support requests. The 'support request' option is there for filing support issues for contributed modules and themes. There are several support options listed on our support page → (Community > Support at the top of Drupal.org) and there is Drupal Slack → . You may get better replies in one of those places.

  • Status changed to Closed: outdated 4 months ago
  • Comment 4 months ago →
    🇳🇿New Zealand quietone
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024