1

I have unit and kernel tests that check for the existence of secrets (via define) in a settings.secrets.php file in my local site (Acquia Cloud convention). This file is not committed to the repo, stored in the database or exported.

When writing a functional test, I ran into an issue (which sounds similar to this one). If I tried to put define in my test file, I would just get an error and test failure saying the constant is undefined.

I came up with this, overriding prepareSettings() to write to the settings file generated for functional tests:

  /**
   * {@inheritdoc}
   */
  protected function prepareSettings() {
    parent::prepareSettings();
    $directory = DRUPAL_ROOT . '/' . $this->siteDirectory;
    copy(DRUPAL_ROOT . '/sites/example.secrets.settings.php', $directory . '/secrets.settings.php');
    $append_line = 'include_once dirname(__FILE__) . \'/secrets.settings.php\';';
    file_put_contents($directory . '/settings.php', $append_line, FILE_APPEND);
  }

The file that is copied just contains define statements with fake values.

Is this a valid approach to fixing this problem in a functional test, or did I miss something else and don't need the above code?

Update:

The code in the question only works for Functional tests as they have that method. Lower level kernel and unit tests have no access to that.

Instead, I found that you can add constants to phpunit.xml and then the tests have them defined:

    <php>
        <const name="MYMODULE_API_URL" value="https://api.myproject.localhost"/>
        <const name="MYMODULE_API_KEY" value="123456789"/>
        <!-- Set error reporting to E_ALL. -->
        <ini name="error_reporting" value="32767"/>

There appears to be one exception though - BrowserTests that have calls to drupalGet can still throw Use of undefined constant exception and fail the test. I can't figure that part out. I also tried using a testing profile that does not enable page or dynamic cache - same result. For now I had to comment out the drupalGet calls until I figure it out later.

However by adding it to phpunit.xml, you cannot do it in prepareSettings or you get a 'constant already defined'. So it appears that it is aware of the existing of this value.

Why do non BrowserTests not adhere to constants that are set either in code or in phpunit.xml, but any other tests do?

Update 2:

Here is the code in the test. The lines in the first loop for drupalGet will fail with the error, but curiously, the last block passes just fine:

    foreach ($permitted as $account) {
      $this->drupalLogin($account);

      foreach ($this->entity_types as $entity_type) {
        $this->drupalGet('node/' . $entity_type['nid'] . '/edit');

        if ($entity_type['response'] === 200) {
          $this->assertLinkByHref('/node/' . $entity_type['nid'] . '/update');
          $this->assertLinkByHref('/node/' . $entity_type['nid'] . '/data');
        } else {
          $this->assertNoLinkByHref('/node/' . $entity_type['nid'] . '/update');
          $this->assertNoLinkByHref('/node/' . $entity_type['nid'] . '/data');
        }

        $this->drupalGet('/node/' . $entity_type['nid'] . '/update');
        $this->assertResponse($entity_type['response']);

        $this->drupalGet('/node/' . $entity_type['nid'] . '/data');
        $this->assertResponse($entity_type['response']);
      }

      $this->drupalLogout();
    }

    // As someone without the specific permission
    $this->drupalLogin($this->staff);

    foreach ($this->entity_types as $entity_type) {
      $this->drupalGet('node/' . $entity_type['nid'] . '/edit');
      $this->assertNoLinkByHref('/node/' . $entity_type['nid'] . '/update');
      $this->assertNoLinkByHref('/node/' . $entity_type['nid'] . '/data');
      $this->drupalGet('/node/' . $entity_type['nid'] . '/update');
      $this->assertResponse(403);
      $this->drupalGet('/node/' . $entity_type['nid'] . '/data');
      $this->assertResponse(403);
    }
0

The code in the question only works for Functional tests as they have that method. Lower level kernel and unit tests have no access to that, and thus, they would fail.

Instead, I found that you can add constants to phpunit.xml and then the tests have them defined:

    <php>
        <const name="MYMODULE_API_URL" value="https://api.myproject.localhost"/>
        <const name="MYMODULE_API_KEY" value="123456789"/>
        <!-- Set error reporting to E_ALL. -->
        <ini name="error_reporting" value="32767"/>

Then you can remove the prepareSettings method from functional tests. However, there seems to be another bug (that I can't track down) where tests that use drupalGet can sometimes fail with an undefined constant error, even though it is defined in the configuration file (you can do it in code too, and will still fail).

My only guess here is that its an issue with a new process spawn not getting the defined configuration from phpunit.xml, or files are loaded out of order (test file constants aren't seen?).

I settled on the following. I left the constants defined in phpunit.xml so my unit/kernel tests did not need them littered in the tests. For functional tests, I put prepareSettings back in with some changes:

  protected function prepareSettings() {
    parent::prepareSettings();
    $directory = DRUPAL_ROOT . '/' . $this->siteDirectory;
    copy(DRUPAL_ROOT . '/sites/functional.settings.php', $directory . '/functional.settings.php');
    $append = 'include dirname(__FILE__) . \'/functional.settings.php\';';
    file_put_contents($directory . '/settings.php', $append, FILE_APPEND | LOCK_EX);
  }

The contents of the file:

/**
 * @file
 * Functional tests settings file.
 *
 * There is a weird bug where constants are not recognized in certain cases
 * in functional tests, despite them being defined in phpunit.xml.dist.
 *
 * Functional tests should include any required constants here to avoid this
 * bug.
 *
 * @see https://drupal.stackexchange.com/questions/292713/functional-tests-report-constants-are-undefined-even-if-the-constant-is-set-in
 */

if (!defined('MYMODULE_API_URL')) {
  define('MYMODULE_API_URL', 'https://api.docker.localhost');
}

if (!defined('MYMODULE_API_key')) {
  define('MYMODULE_API_key', 'foobar');
}

Now, with the functional test uncommenting all the calls to drupalGet, all tests are passing with no errors about undefined constants.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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