Running behat tests fail with BLT - Trait 'AwaitTrait' not found (Lightning Layout)

Thanks for filing this! A little bit of background:

The BLT maintainers identified this a few weeks ago and a fix was committed, but there was some confusion about which version of Lightning would start affecting BLT. So, sorry that this even came up.

The committed (but not yet in a BLT release) solution is to exclude Lightning's extensions from being autoloaded. You can implement this by modifying the DrupalExtension config in tests/behat/example.local.yml to look like this:

    Drupal\DrupalExtension:
      drupal:
        # This must be an absolute path.
        drupal_root: ${docroot}
      drush:
        alias: '@self'
      subcontexts:
        paths: [ ]
        autoload: 0

That said, I'm not sure why we didn't globally namespace those. I think we only meant for them to be used internally, but maybe that could be up for debate?

I'll ask @phenaproxima who wrote them to chime in tomorrow. Thanks!

Indeed, our test contexts are only meant for internal use, which is why I didn't bother to namespace them. If we created a testing package, containing the contexts, but intended for use by others, I would definitely put them into a namespace. But so far there's not quite been enough interest to undertake a project like that.

The BLT change referenced above does get the tests running, but I ran into a separate issue presumably caused as a result of the change. The change prevents subcontexts from autoloading and as a result, features with steps defined in Lightning's subcontext are no longer finding that definition:

Then I should not see an 'Edit' link

22 scenarios (21 passed, 1 undefined)
223 steps (222 passed, 1 undefined)
4m24.02s (103.39Mb)

--- Drupal\FeatureContext has missing steps. Define them with these snippets:

    /**
     * @Then I should not see an :arg1 link
     */
    public function iShouldNotSeeAnLink($arg1)
    {
        throw new PendingException();
    }

[Testing\Behat]  Exit code 1
[error]  Behat tests failed!
[error]  Command `tests:behat ` exited with code 1.

The above was fixed by including the path that contains Lightning's subcontext (as documented here:

      subcontexts:
        paths:
          - /var/www/dojfoia/docroot/profiles/contrib/lightning/tests
        autoload: 0

Tests are now passing. Is this the right approach to take?

We should just fix the bug instead of changing collaborating projects to compensate for it. That BLT "fix" breaks a lot of other things.

I intend to remove AwaitTrait from Lightning soon; it's going to be in Lightning Dev only, which is an internal tool. The real "fix", to me, is to move some of these things into either Drupal Extension, or a generic set of Behat contexts that both Lightning and BLT (and other projects, potentially) can take advantage of.

Moved this back to Lightning's issue queue because Lightning Layout's issue queue isn't open until #2933252: Support individual components outside of profile is fixed. And I think you just exposed a bug in D.O by being able to move it there :/

Changing the component in question.

I have an update here. Happily, the news is good.

In discussion with @balsama this morning, I realized that the problem here is not, in fact, the namespacing; it's the fact that AwaitTrait cannot be autoloaded. Drupal Extension cannot autoload it because it's a trait (and therefore not discoverable), and consumers of Lightning cannot autoload it because it is part of the private, internal Lightning Dev package. (You can add that package to your composer.json as a repository, but this is not a realistic solution for people who are using BLT for their various projects.)

The solution we hit on was to move AwaitTrait, and all the contexts in Lightning Dev, to Lightning Core. They are all still in the global namespace, but in a public package that needs to be consumed by anything that is using Lightning components. AwaitTrait is specifically mentioned in Lightning Core's classmap, and Drupal Extension can take care of autoloading the contexts.

We committed this change to both the 8.x-1.x and 8.x-2.x branches of Lightning Core.

I then tested it using BLT. Here is what I did, just for information's sake.

First, I confirmed the failure. I followed BLT's directions to create a new project. I then required Lightning 3.0.2, installed everything in Drupal VM, and tried to run the blt tests:behat command. As expected, it failed epically and nearly instantly with the error described in the IS.

I then ran vagrant destroy to blow away the VM, then I required the 8.x-3.x branch of Lightning (composer require acquia/lightning:dev-8.x-3.x) and rebuilt the VM. When I ran the blt tests:behat command, they passed without any incident.

As far as I can tell, this means we've got it licked. I'd like @TravisCarden or some other knowledgeable person to confirm that before I close this issue, though.

Running our stuff against the latest dev fixed the behat issues that we were running into.

Any chance of giving us a tagged release?

@zseguin thanks for testing. We're trying to get #2947577: Lightning Versions config depends on Lightning profile - which makes it incompatible with Config Installer and impossible to import exported config fixed too. Then we'll tag another release.

@phenaproxima, the approach outlined seems reasonable in terms of avoiding the presenting problem. I can't help but wonder, though, why we would put anything in the global namespace to begin with. I've always taken that for something of an antipattern. Additionally, I noticed that the traits are in SomeTrait.inc files, and I wonder if that's significant. The standard in core is SomeTrait.php, and it makes me wonder (without having looked) whether that's significant from an autoloading standpoint. Both those points are just musing on my part. I share in case it's helpful, but please don't take me as arguing a case or asking for justification. As long as it works (thanks again, @zseguin) I have no concerns.

@TravisCarden, it's a small point for sure; but, to me, a namespace is to be used for "supported" code, like a cohesive, distributed package; basically, stuff that's not internal and specific to the project. The contexts are strictly for testing. Ideally I'd like to move them into their own package, completely decoupled from Lightning or any of its components, which would mean putting the contexts into proper namespaces. But until that happens, they're just there to facilitate Lightning's tests running properly, so I don't mind being a little sloppy for now.

This should be fixed in the latest release of Lightning.