Create nightwatch command to install modules

- adds a command to enable modules
- @samuel.mortenson 👏 for a ton of PHP help.

browser
  .installDrupal({})
  .moduleInstall(['test_page_test']);

Updated the Symfony command docs a bit.

Removed permission changes accidentally put into the patch...

I am wondering, why do we not move this into the install command? Given that the setup script needs modules to be installed already, I think moving it there seems to make sense for me.

On the other hand, I am hoping that all setup is done in the setup class. From my perspective we don't want to invent a domain specific language (DSL), replicating all possible setups you can do in Drupal. Much like behat and its DSL is a great tool for custom sites, and it's model breaks down for a complexity needed for Drupal core, so would it, from my perspective, on nightwatch too.

When writing a setup file is hard, maybe we should make that better.

@dawehner I think we have to decide how much PHP we expect people to write when making new Nightwatch tests.

@drpal brought up that as a Javascript developer, he would prefer to write as little PHP as possible. If we add enough commands to Nightwatch it's feasible that for simple tests it could be possible to omit the setup file completely.

My preference is always going to be write nearly zero php code for these tests.

@alexpott, @drpal and @dawehner had a discussion about these commands this morning.
There are some constraints we talked about:

• We want to avoid forcing people to write PHP.
• We want to avoid coupling with the PHP of Drupal directly
• Avoiding test level operations. Once you have setup the site, you should stop modifying it.

One suggestion we end up with is:

• Write some test module which enables REST apis + something like jsonrpc (this can totally be custom for tests)
• Add some level of commands but don't make them available during the actual test run, just during setup

We want to avoid forcing people to write PHP.

Avoiding test level operations. Once you have setup the site, you should stop modifying it.

Add some level of commands but don't make them available during the actual test run, just during setup

Maybe I don't understand - are you proposing that the setup file does everything required to run the test? Wouldn't that mean that a setup file, written in PHP, is always required to run Nightwatch tests? I'm not sure how that lets people avoid writing PHP.

Write some test module which enables REST apis + something like jsonrpc (this can totally be custom for tests)

Did you plan this as a replacement for the current setup file? In my opinion it would be great if most operation could be done through APIs, but there's probably always going to be some edge cases why it might be useful to keep the setup file as an alternative option. Also, do you think this is something that should block this issue or could we work on that in another issue?

@lauriii

From my perspective, the setup file is a confusing pattern. Some operations are part JavaScript and part PHP. I think it's perfectly acceptable to have PHP perform some operations under the covers, however I'm not thrilled with both components being needed for a single operation.

Apart from the php/js discussion above, I created a new patch because the one in #4 had some issues (no timelimit, wrong function names etc).

After reading #15 here #2973879: Add login/logout Nightwatch commands (and a Drupal "login" command to allow for that), I'm thinking this issue is a "won't fix" because it is decided enabling module won't be done in PHP (at least not in core)?

Even though we don't want to provide PHP command for installing modules, it could be done through the UI like we create roles and set permissions on #2973879: Add login/logout Nightwatch commands (and a Drupal "login" command to allow for that).

Currently I don't think it's possible to write Nightwatch tests for contrib modules at all, so this issue is a major blocker to Nightwatch being usable to anyone outside of core. Setup classes passed to the drupalInstall() function need to be autoloaded, and contrib modules aren't installed after Drupal is installed and as a result won't have their setup files autoloaded.

I didn't realize the setup file had to be a path to a file, not a class. :facepalm:

I don't think that installing modules via UI in the command is a good idea.

1. Some modules have dependencies, that's a separate screen with the confirmation form.
2. Hidden modules can't be clicked.
3. Also hidden themes (which are basically need the same or almost the same command in this issue or another) can't be clicked.

@pingwin4eg

Visual testing with real browsers.

@nevergone, sorry, I don't understand your comment.

I know @samuel.mortenson redacted his previous comment in #18, but just to clarify if anybody needs a workaround until this issue is completed, you can currently use nightwatch in contrib, you just have to jump through a few hoops. We're doing it in the performance budget module:

  before: function(browser) {
    browser.drupalInstall({
      setupFile: 'modules/contrib/performance_budget/tests/src/TestSite/TestSiteInstallTestScript.php',
    });
  },

And then in the TestSiteInstallTestScript.php you just have something like this:

namespace Drupal\TestSite;

/**
 * Setup file used by Nightwatch tests.
 */
class TestSiteInstallTestScript implements TestSetupInterface {

  /**
   * {@inheritdoc}
   */
  public function setup() {
    $modules = [
      'field',
      'node',
      'user',
      'web_page_archive',
      'performance_budget',
    ];
    \Drupal::service('module_installer')->install($modules);
    require 'dbdump.php';
  }

}

In hindsight, I probably should change that path to be something relative to __dirname or something like that that though, in case the module gets installed elsewhere, but that's a problem for another day.

This looks like it was completed in #3255809: Add nightwatch tests for toolbar

Change record is at https://www.drupal.org/node/3264978