jhedstrom / drupaldriver Goto Github PK

Follow up issue after merging of #11

The current solution breaks in Drupal 8 since \Drupal\Driver\Cores\AbstractCore is supposed to be Drupal core agnostic, so in there we cannot refer to Drupal 7 specifics like the LANGUAGE_NONE constant, which is not available in Drupal 8.

One possible solution would be to add the $entity object to the field handler constructor, so we can delegate all core specific logic to handler implementations, so from:

public function getFieldHandler($entity_type, $field_name, $language);

We would have:

public function getFieldHandler($entity, $entity_type, $field_name);

I'm trying to create an entity with a file field, unfortunately it fails.
Whereas quite the same works for an entity with an "image field"

Drupal\Driver\Fields\Drupal8\FileHandler should have almost the same behaviour as Drupal\Driver\Fields\Drupal8\ImageHandler

In our implementation of DrupalDriver - we don't use Behat but we do use PHPUnit and Selenium - we go to the Drupal root folder after bootstrapping to keep libraries_get_libraries() from failing.

    // Bootstrap Drupal.
    $driver->bootstrap();

    // Needed for code that does not use DRUPAL_ROOT, but instead relies
    // on Drupal root being the current working directory.
    // Like libraries_get_libraries().
    chdir($drupal_directory);

Why is DrupalDriver going back to the previous folder instead of staying at the Drupal root folder?

We should add ->accessCheck(FALSE) to our EntityQuery in the D8 EntityReferenceHandler.

Otherwise it will fail when asked to create entities that reference other entities the current user cannot access. The Driver shouldn't really care about the current user unless explicitly told to, as it's methods are often used to set up context for a test rather than describe actions of a test user.

Fatal error: Uncaught TypeError: Argument 1 passed to spec\Drupal\Driver\Cores\Drupal6Spec::let() must be an instance of Drupal\Component\Utility\Random, PhpSpec\Wrapper\Collaborator given in /home/travis/build/jhedstrom/DrupalDriver/spec/Drupal/Driver/Cores/Drupal6Spec.php:15

This just started yesterday... It seems to be the same issue as phpspec/phpspec#659, but that was resolved long ago.

In #161 a DateRangeHandler was introduced, but it is not working as expected because it assumes that the start date will have the key 0 and the end date will have the key 1. We are using Behat DrupalExtension for testing our fields, and it is passing the correct compound field property keys value and end_value.

Ref. RawDrupalContext::parseEntityFields().

Here's my setup: When a user of a specifc role gets created some nodes with enabled revisions get created automatically. When behat tries to delete the user I get the following exception:

  ╳  exception 'Drupal\Core\Entity\EntityStorageException' with message 'Default revision can not be deleted' in /var/www/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php:339
  ╳  Stack trace:
  ╳  #0 /var/www/web/core/modules/node/node.module(470): Drupal\Core\Entity\ContentEntityStorageBase->deleteRevision('1004')
  ╳  #1 /var/www/web/core/modules/node/node.module(720): node_revision_delete('1004')
  ╳  #2 /var/www/vendor/drupal/drupal-extension/src/Drupal/DrupalExtension/Context/RawDrupalContext.php(232): node_user_predelete(Object(Drupal\user\Entity\User))
  ╳  #3 [internal function]: Drupal\DrupalExtension\Context\RawDrupalContext->cleanUsers(Object(Behat\Behat\Hook\Scope\AfterScenarioScope))
  ╳  #4 /var/www/vendor/behat/behat/src/Behat/Testwork/Call/Handler/RuntimeCallHandler.php(104): call_user_func_array(Array, Array)
  ╳  #5 /var/www/vendor/behat/behat/src/Behat/Testwork/Call/Handler/RuntimeCallHandler.php(60): Behat\Testwork\Call\Handler\RuntimeCallHandler->executeCall(Object(Behat\Testwork\Hook\Call\HookCall))
  ╳  #6 /var/www/vendor/behat/behat/src/Behat/Testwork/Call/CallCenter.php(129): Behat\Testwork\Call\Handler\RuntimeCallHandler->handleCall(Object(Behat\Testwork\Hook\Call\HookCall))
  ╳  #7 /var/www/vendor/behat/behat/src/Behat/Testwork/Call/CallCenter.php(82): Behat\Testwork\Call\CallCenter->handleCall(Object(Behat\Testwork\Hook\Call\HookCall))
  ╳  #8 /var/www/vendor/behat/behat/src/Behat/Testwork/Hook/HookDispatcher.php(74): Behat\Testwork\Call\CallCenter->makeCall(Object(Behat\Testwork\Hook\Call\HookCall))
  ╳  #9 /var/www/vendor/behat/behat/src/Behat/Testwork/Hook/HookDispatcher.php(58): Behat\Testwork\Hook\HookDispatcher->dispatchHook(Object(Behat\Behat\Hook\Scope\AfterScenarioScope), Object(Behat\Behat\Hook\Call\AfterScenario))
  ╳  #10 /var/www/vendor/behat/behat/src/Behat/Behat/Hook/Tester/HookableScenarioTester.php(89): Behat\Testwork\Hook\HookDispatcher->dispatchScopeHooks(Object(Behat\Behat\Hook\Scope\AfterScenarioScope))
  ╳  #11 /var/www/vendor/behat/behat/src/Behat/Behat/EventDispatcher/Tester/EventDispatchingScenarioTester.php(114): Behat\Behat\Hook\Tester\HookableScenarioTester->tearDown(Object(Behat\Behat\Context\Environment\InitializedContextEnvironment), Object(Behat\Gherkin\Node\FeatureNode), Object(Behat\Gherkin\Node\ScenarioNode), false, Object(Behat\Testwork\Tester\Result\TestResults))
  ╳  #12 /var/www/vendor/behat/behat/src/Behat/Behat/Tester/Runtime/RuntimeFeatureTester.php(84): Behat\Behat\EventDispatcher\Tester\EventDispatchingScenarioTester->tearDown(Object(Behat\Behat\Context\Environment\InitializedContextEnvironment), Object(Behat\Gherkin\Node\FeatureNode), Object(Behat\Gherkin\Node\ScenarioNode), false, Object(Behat\Testwork\Tester\Result\TestResults))
  ╳  #13 /var/www/vendor/behat/behat/src/Behat/Behat/Hook/Tester/HookableFeatureTester.php(72): Behat\Behat\Tester\Runtime\RuntimeFeatureTester->test(Object(Behat\Behat\Context\Environment\UninitializedContextEnvironment), Object(Behat\Gherkin\Node\FeatureNode), false)
  ╳  #14 /var/www/vendor/behat/behat/src/Behat/Behat/EventDispatcher/Tester/EventDispatchingFeatureTester.php(71): Behat\Behat\Hook\Tester\HookableFeatureTester->test(Object(Behat\Behat\Context\Environment\UninitializedContextEnvironment), Object(Behat\Gherkin\Node\FeatureNode), false)
  ╳  #15 /var/www/vendor/behat/behat/src/Behat/Testwork/Tester/Runtime/RuntimeSuiteTester.php(63): Behat\Behat\EventDispatcher\Tester\EventDispatchingFeatureTester->test(Object(Behat\Behat\Context\Environment\UninitializedContextEnvironment), Object(Behat\Gherkin\Node\FeatureNode), false)
  ╳  #16 /var/www/vendor/behat/behat/src/Behat/Testwork/Hook/Tester/HookableSuiteTester.php(73): Behat\Testwork\Tester\Runtime\RuntimeSuiteTester->test(Object(Behat\Behat\Context\Environment\UninitializedContextEnvironment), Object(Behat\Testwork\Specification\GroupedSpecificationIterator), false)
  ╳  #17 /var/www/vendor/behat/behat/src/Behat/Testwork/EventDispatcher/Tester/EventDispatchingSuiteTester.php(72): Behat\Testwork\Hook\Tester\HookableSuiteTester->test(Object(Behat\Behat\Context\Environment\UninitializedContextEnvironment), Object(Behat\Testwork\Specification\GroupedSpecificationIterator), false)
  ╳  #18 /var/www/vendor/behat/behat/src/Behat/Testwork/Tester/Runtime/RuntimeExercise.php(71): Behat\Testwork\EventDispatcher\Tester\EventDispatchingSuiteTester->test(Object(Behat\Behat\Context\Environment\UninitializedContextEnvironment), Object(Behat\Testwork\Specification\GroupedSpecificationIterator), false)
  ╳  #19 /var/www/vendor/behat/behat/src/Behat/Testwork/EventDispatcher/Tester/EventDispatchingExercise.php(70): Behat\Testwork\Tester\Runtime\RuntimeExercise->test(Array, false)
  ╳  #20 /var/www/vendor/behat/behat/src/Behat/Testwork/Ordering/OrderedExercise.php(80): Behat\Testwork\EventDispatcher\Tester\EventDispatchingExercise->test(Array, false)
  ╳  #21 /var/www/vendor/behat/behat/src/Behat/Testwork/Tester/Cli/ExerciseController.php(146): Behat\Testwork\Ordering\OrderedExercise->test(Array, false)
  ╳  #22 /var/www/vendor/behat/behat/src/Behat/Testwork/Tester/Cli/ExerciseController.php(108): Behat\Testwork\Tester\Cli\ExerciseController->testSpecifications(Object(Symfony\Component\Console\Input\ArgvInput), Array)
  ╳  #23 /var/www/vendor/behat/behat/src/Behat/Testwork/Cli/Command.php(63): Behat\Testwork\Tester\Cli\ExerciseController->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
  ╳  #24 /var/www/vendor/symfony/console/Command/Command.php(259): Behat\Testwork\Cli\Command->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
  ╳  #25 /var/www/vendor/symfony/console/Application.php(844): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
  ╳  #26 /var/www/vendor/symfony/console/Application.php(192): Symfony\Component\Console\Application->doRunCommand(Object(Behat\Testwork\Cli\Command), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
  ╳  #27 /var/www/vendor/behat/behat/src/Behat/Testwork/Cli/Application.php(121): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
  ╳  #28 /var/www/vendor/symfony/console/Application.php(123): Behat\Testwork\Cli\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
  ╳  #29 /var/www/vendor/behat/behat/bin/behat(32): Symfony\Component\Console\Application->run()
  ╳  #30 {main}
  │
  └─ @AfterScenario # Drupal\DrupalExtension\Context\DrupalContext::cleanUsers()

This is coming from node_user_predelete() which deletes all revisions of a user and chokes about the default revision.

I tried to debug the code but I am out of luck. Running the same code from /devel/php does not throw an exception.

Any ideas what might go wrong?

We already have a ListTextHandler for Drupal 7 that converts labels for allowed value fields to their storage values. We need in Drupal 8 the various list field type handlers provided by the text and options core modules.

• ListStringHandler
• ListFloatHandler
• ListIntegerHandler

Running the behat test, gives me `Call to undefined function Drupal\Driver\Cores\conf_path() in /Library/WebServer/Documents/cegeka/behat-demo/vendor/drupal/drupal-driver/src/Drupal/Driver/Cores/Drupal8.php on line 291``
Whe I look in the source of drupal 8, conf_path is no longer a function.

I was battling with a field handler not working as expected when I realised it was actually looking for a DatestampHandler rather than a DatetimeHandler. I'd like to create a DatestampHandler class but I'm not sure where to put it so it will get autoloaded in my project. Any advice?

Tests are currently failing on travis due to coding standard issue changes.

Not sure if i'm reading everything correct in the class definitions, but if i'm not mistaken it's not possible to test a multisite setup with the drupal driver.

More specific, i'm looking for something to do tests like:
Given I Create node A on site1
And Check node A on site1
And I Create node B on site2
And Check node B on site2

The only option inside the DrupalDriver seems to be drupal_root. This needs to point to the root of the drupal installation, and looks in there for the 'default'/settings.php all the time.
It seems to me (although hoping i'm wrong) there is no way to set this to docroot/sites/site2.

This error happens when running with drush 9:

 The "--nocolor" option does not exist.

When running composer install/update/require -o, I get the following warning:

Warning: Ambiguous class resolution, "Drupal\Component\Utility\Random" was found in both "$baseDir . '/web/core/lib/Drupal/Component/Utility/Random.php" and "vendor/drupal/drupal-driver/src/Drupal/Component/Utility/Random.php", the first will be used.

According to core's change record https://www.drupal.org/node/2456869:

"Drupal 8 has a generic Entity reference field included in core, and, until Drupal 8.0.0-beta10, it also had the old Taxonomy reference field from Drupal 7. In order to reduce code duplication and improve the developer and site-building experience, the Taxonomy reference field has been removed."

Let's remove the D8 taxonomy reference field handler from the driver; it's unnecessary maintenance.

Since the Mail System module is necessary for full HTML emails (coupled usually with swiftmailer), it would be good to support that here since the feature added in #134 only supports the core mail manager's approach of sending mail.

I'm using drupal extension and the requirement is PHP 5.3.5 (http://behat-drupal-extension.readthedocs.org/en/3.0/requirements.html) but i get something like:

This is becauseof the short array syntax, that 5.3.10 don't allow (I think).

When upgrading to gherkin 4.5.1 if I run tests via paths (i.e. behat features/my.feature) then i get errors like:

[Behat\Testwork\Tester\Exception\WrongPathsException]
No specifications found at path(s) features/my.feature. This might be because of incorrect paths configuration in your suites.

I'm not sure what has changed in gherkin but when it tries to validate the path the pwd is DRUPAL_ROOT and it fails (it is comparing features/my.feature to web/features). If i comment out the following line in Drupal/Driver/Cores/Drupal8.php:30 'chdir(DRUPAL_ROOT);' then it works (but on an empty cache you get all sorts of weird issues when not in DRUPAL_ROOT).

The problem goes away if I force a downgrade via the following versions in composer:

"behat/behat": ">=3.1 <3.4",
"behat/gherkin": ">=4.4 <4.5",

Directory structure (using drupal-composer):

features/...
web/...
vendor/...
behat.yml
...

Major component versions when failing:

• drupal/core: 8.3.7
• drupal/drupal-extension: v3.3.1
• drupal/drupal-driver: v1.2.1
• behat/behat: v3.4.1
• behat/gherkin: v4.5.1

Major component versions when working:

• drupal/core: 8.3.7
• drupal/drupal-extension: v3.3.1
• drupal/drupal-driver: v1.2.1
• behat/behat: v3.3.1
• behat/gherkin: v4.4.5

Serveral methods that are implemented on DrupalDriver are not documented in the DriverInterface.

Currently it seems that the '1.0' branch is set as the default. This branch is now showing up on the main page, and pull requests are made against 1.0 by default.

Could you consider making the 'master' branch the default? This is the tradition on github - it allows people to always see the latest code, and pull requests are made are by default made against this.

Please create a new version :).

Thanks!

I have a bamboo based build system that is reporting failed Behat tests due to:

Warning: Illegal string offset 'drush-version' in vendor/drupal/drupal-driver/src/Drupal/Driver/DrushDriver.php line 139

Ive since updated my local version to the latest as well but dont see the issue when running the tests locally.

Running on Acquia btw if that has any impact. Running Drupal 7 on Drush 8.

Anyone got any ideas why this would be the case?

EDIT - it seems Acquia have removed part of this in some of their Drupal 8 build tool stuff:

acquia/blt@1f5419b

Is the code used in isLegacyDrush correct based on the above?

First, sorry for not creating a ticket for this when I created the PR. I might have gotten distracted and forgot.

When using the DrupalExtension to creating a new node, or an entity in general, and set a value in an entity reference field, the DrupalDriver fails to look up the entity from the database, as it's trying to look up the label of the entity instead of the key.

Pull request: #94

I'm most of the way there with my Christmas present: an initial rough implementation of

1. Field plugins (real D8 plugins that developer can supplement for their own project); these replace the home-baked Field handlers.
2. Entity plugins (rationalising up all the node, term, user, etc. creation & deletion logic and allowing developers to override/supplement it.
3. Extensive driver-side kernel tests to make sure everything works the same after the refactoring.

I'm thinking this should be for version 2.0; do you have a timeline for that or other things on the roadmap for it?

Currently the default field handler only supports fields that have a single column, and will hard code the column name to 'value'. This is fine for something like a regular text field, but it cannot be used for fields that have multiple columns, or use a different column name.

I propose to allow the use of arrays for the field items in DefaultHandler::expand() that are keyed on the column name.

For example this would allow us to support a complex field such as AddressField without having to write a custom handler:

$values = [
  0 => [
    'country' => 'BE',
    'locality' => 'Brussel',
    'thoroughfare' => 'Louisalaan 1',
    'postal_code' => '1000',
  ],
];

Approach:
Create a method that will place the block in region. Write methods for every Drupal version.

Refer this drupalextension issue.

This project needs a CHANGELOG.md file.

See jhedstrom/drupalextension#150 for the 1.0 version.

Hello,

Just found out why drupaldriver is removing the content from a user 'logged in with "x" role' (behat drupalextension) at the end of the scenario.

Looks like Drupaldriver always takes 'user_cancel_delete' as parameter instead of using the variable user_cancel_method from the Drupal environment it is working on.

I might guess you dont want to leave any traces from the tests on the environment but have a feature with multi scenarios where one make a new node and the following scenarios are checking that node. After the first scenario the node gets deleted and so the following scenarios will always fail...

Any suggestions?

Thanks

Utilizing the module overrides for the mail collection doesn't fully work. It only changes the config in the bootstrap that Behat is running from. Thus, any mails sent by filling out forms, or events that happen in a separate bootstrap go back to using the normal mail collector.

Rather than using module override, I think we'll have to actually save the config (and track the original values), then restore them afterward.

I've just tracked down an issue we've been having for a while, some of our terms were being periodically deleted - this turns out to be an issue with how the Drupal7 Driver creates terms and what it subsequently returns.

The issue is that after doing the taxonomy_term_save() it unnecessarily reloads terms by using taxonomy_get_term_by_name and uses a reset() to return the first term from the list.

This is unnecessary because $term is an object and will have the resulting saved term after taxonomy_term_save() runs. Even though the comments state "there should only be one matching term in a testing context" that can never be safely true, what about free tagging vocabularies which contain user created terms?

I propose we remove the reloading altogether and return $term straight after the save.

I will have a pull request up for this soon.

It seems like we could really do with better tests in the Driver. In particular, tests that show that the desired results are actually performed on Drupal.

This could involves two types of tests:

Kernel tests
Something a bit like D8's kernel tests. At it's simplest this could just be PHP unit tests that call out to the \Drupal container to interrogate the Drupal API.

Extension features
One low hanging fruit might be to run the Drupal extension's @api features on every Driver PR. They're the most complete test suite of expected Driver functionality we currently have.

The challenge
In both cases, I think we need to combine 3 things:

1. A working Drupal installation
2. The code from the Driver PR
3. An autoloader that works well enough for the Driver to reach Drupal

The Drupal Extension does something similar for its tests. I think what it does depends on this magic in this composer.json used in the tests:

  "autoload": {
    "psr-0": {
      "Drupal\\Drupal": "src/",
      "Drupal\\Exception": "src/",
      "Drupal\\DrupalExtension": "src/"
    }

I think this is making classes in the /src folder in travis' root available in the namespace Drupal\DrupalExtension. I suspect this effectively makes it available as a pseudo-package as if it had been composer-required. We should be able to use a similar trick with the Driver. That's how we get the code form the Driver's PR (automatically loaded by Travis into the root folder) to be available as if it was installed in a Drupal project normally.

Would this be enough so that we could make calls like \Drupal::entityTypeManager() from within a Driver test class in tests/Drupal/Tests/Driver invoked by php unit?

If so the basic picture would be:

1. Have a composer.json.dist requiring the drupal extension and with additional autoload parameters similar to the above for the driver; copy this to composer.json and run composer install.
2. Use Drush to install Drupal in a subfolder
3. Copy the various Drupal extension features etc. files out of the extension to where they would be in a normal Drupal project, and set up those Behat tests to run
4. Use php unit to run kernel-like tests

Does this all seem like a good direction to go in?

When I run
Warning: Invalid argument supplied for foreach() in /var/www/fta/vendor/drupal/drupal-driver/src/Drupal/Driver/Fields/Drupal7/DefaultHandler.php line 21

Because "$values" isn't always an array, it generates the above error.

public function expand($values) {
    $return = array();
    foreach ($values as $value) {
      $return[$this->language][] = array('value' => $value);
    }
    return $return;
  }

This seems to be a problem for PHP 5.5.9-1ubuntu4.5
but not PHP 5.6.2 (cli)

Casting the variable might solve this:
foreach ((array)$values as $value)

Scenario:

    Given I am viewing a "News" content:
      | title      | News feature: News item 1 |
      | body       | This is a news item       |
      | field_date | 2018-02-25 07:45:45       |
      | language   | en                        |

Now that core supports Datetime ranges, we should too.

I am using the the next given:

 Given I a viewing a "News" content:
      | title      | News feature: News item 1 |
      | body       | This is a news item       |
      | field_date | 2018-02-25 07:45:45       |
      | language   | en                        |

Anyone has a suggestion on how to add domain selection from domain access module? The domain information is not included in field.info.class.inc

Should this be for example in de Drupal7 Class (nodeCreate), or should we create some kind of hook to alter this ...

Think I possibly added this to the wrong place:

drush-ops/behat-drush-endpoint#3

As per that ticket, using createNode or createNodes with fields that arent core fields ends in error:

Error: __clone method called on non-object in behat-drush-endpoint\behat.d7.drush.inc,

Ive been trying to get this running for a few months now and was hopeful after seeing the recent releases containing fixes to this area, but im still plagued by the above.

So for example this:

drush @myAlias behat create-node '{"type":"News", "title":"new node", "author":"test.editor", "status":1}'

will work ok, but this:

drush @myAlias behat create-node '{"type":"News", "title":"new node", "author":"test.editor", "status":1, "field_my_new_field":"test text"}'

will error as above. That new field is mandatory as well.

The link field in drupal 8 core supports linking to internal pages and is done via an autocomplete link, saved as an entity:node/{nid} url.

The LinkHandler class doesn't support this. It should be similar to how EntityReferenceHandler uses the label key and searches for an entity and replaces the value if so.

Currently attempting this will result in an error on the page:

InvalidArgumentException: The URI 'Test 123' is invalid. You must use a valid URI scheme. in Drupal\Core\Url::fromUri() (line 281 of core/lib/Drupal/Core/Url.php).

For 2.0, it would be nice to only support modern php, but this would leave Drupal 7 (and certainly 6) behind.

Thoughts?

The new EntityContext (and possibly pre-existing code) don't provide very informative errors if the entity or bundle doesn't exist. (Run entity.feature against aa Drupal 8 installation using the Minimal profile to see examples).

Instead you get a lot of:
Catchable Fatal Error: Object of class stdClass could not be converted to string in vendor/drupal/drupal-driver/src/Drupal/Driver/Cores/Drupal8.php line 438

$driver->setCoreFromVersion(); does not work with core Drupal7 because its __construct() requires a $random argument, in contrary to core Drupal8.

We work around this by setting the Driver core property explicitly instead of using setCoreFromVersion(): $driver->core = new \Drupal\Driver\Cores\Drupal7($path, $uri, new Random())

But ideally, both core drivers should work alike.

Currently the LinkHandler disregards and input for the options since it sets a empty array().
Maybe the $value[2] could be used, split similarly to the Title and Uri?

We use TableNodes to populate the Link value using: "Link title - http://urihere.com"
We'd like to supply the link options in the form of an array like:
"Link title - http://urihere.com - attributes[target]=_blank"

Pull request for this issue: #107

It would be nice to do

Given an "article" content:
| title | promote |
| test  | Yes         |

instead of

Given an "article" content:
| title | promote |
| test  | 1            |

Using numeric values for booleans does not seem good BDD.
#44 seems to address the issue for D7; looks like we need a BooleanHandler for D8.

My suggestion is to try to use the field's 'off_label' and 'on_label' settings; if that fails then try true/false, 0/1, one/off, yes/no. If the value does not match any of these, throw an exception.

Doing this in a translation-sensitive way will be the clever part.

I'm using behat-drush-endpoint on a Pantheon site and was having trouble creating a term with behat. The step Given a/an :vocabulary term with the name :name was failing with (RuntimeException) as the only output. I eventually found out that the error message was "Command not supported as typed." but it lives in $process->getOutput() and not in $process->getErrorOutput(). Perhaps this is an issue in the behat drush command, but I wasn't sure if getOutput() was a valid place for error output.

When I ran the resulting drush command manually:

drush @pantheon.alias  behat  --nocolor= create-term '{"name":"Test Term","vocabulary_machine_name":"Test Vocab","description":"g&lx\\#r)J\"kBm~?>Z^sY$;v23l=Mi7%Jsn|w93AgHCJ\/UBw9oZ|ss>+I#|'\''\\h*TXlU8i%lJ4{e-~Jr\"*^Rs81v=z5~8u$3u@M;@y#h.boHf*NX&(DI}AiR!V0H,i8^h\/3<M$NEz3]@`<4f3v58nzq{:e[Y PX5lN#$5N>zat\/u@aye$a@0q Lf7H3OT3Xm,&2^><;<4Vg(l8>7EiRljaggt~IOwbWuTlB`B*`6LM>}+E3WbzA8Ez[DfVH\"C}#}0"}'

It did produce a non-zero exit code.

The number of contributors to the project is growing. It would be good for the consistency of the code base to follow a particular coding standard. Currently a mix of standards is used.

Since this project is closely related to Drupal we can maybe opt to use the Drupal coding standards?

Looks like there is an incorrect negation operator - this change would fix it?

--- a/src/Drupal/Driver/Fields/Drupal8/EntityReferenceHandler.php
+++ b/src/Drupal/Driver/Fields/Drupal8/EntityReferenceHandler.php
@@ -26,7 +26,7 @@ class EntityReferenceHandler extends AbstractHandler {
 
     // Determine target bundle restrictions.
     $target_bundle_key = NULL;
-    if (!$target_bundles = $this->getTargetBundles()) {
+    if ($target_bundles = $this->getTargetBundles()) {
       $target_bundle_key = $entity_definition->getKey('bundle');
     }
 

The drivers depend on DrupalSubContextFinderInterface, which still resides in the Drupal Extension.

The .travis.yml file could use some cleanup (eg, use composer test, use parallel linting, etc).

Per this blog post:

https://pantheon.io/blog/better-behavior-driven-development-remote-servers

And the merged PR:

#56

It sounds like this should be possible...

But how to get this to actually work? I've tried setting up a Behat enviroment (with dev-master of both drupal/drupal-extension and drupal/drupal-driver) that registers the 'drush' driver, but not the 'drupal' driver, and every time I try to use a node creation step (from the DrupalContext - not DrushContent, which doesn't have any steps for creating nodes) it gives me an exception with the message: Driver "drupal" is not registered.

Do I need to make a custom context with node creation steps that use the underlying Drush driver directly? Will the DrupalContext be updated at some point to use the Drush driver for node creation, or will there be a new context added?

Thanks for your help!