WordPressPluginContext - add missing methods

[Chrico]

First of all i've updated the thereArePlugins-method to re-use the new internal functions. Also the method will now throw a Exception if a plugin is not successfully activated/deactivated.

Follwing new resuable actions are defined:

---

Uninstall:

• I uninstall the plugin :plugin
• The plugin :plugin is uninstallable
• The plugin :plugin is not uninstallable

---

Activate:

• I activate the plugin :plugin
• The plugin :plugin is activated

---

Deactivate:

• I deactivate the plugin :plugin
• The plugin :plugin is deactivated

---

Next step should be to extend the actions to optional network_wide

[stephenharris]

Thanks @Chrico, I was not aware of the is_uninstallable_plugin() function.

Just one thing - could you run vendor/bin/phpcbf, and commit the changes ;)

[Chrico]

Sure @stephenharris . The code formatting is now done, but the Travis CI still fails because of some broken Behat-tests?!

I also added some new tests for the new actions in plugins.feature.

Edit: I also removed in this pull the unnecessary "user"-table for "I have a vanilla wordpress installation", since the table is the same as the default when no table is there.

[stephenharris]

@Chrico regarding the failing test, I've opened an issue for this. I've seen it occasionally on Travis and running locally. Normally re-running the test 'fixes' it, but I want to come up with a more robust solution: #10

I've just noticed the step definitions have @And in the doc block. This should be @Given, or @When or @Then depending on how they are used (note, in the .feature file you can still use @And and it 'inherits' from the one above.

As you can see, the tests you've added are not running as Behat can't find the step implementation: https://travis-ci.org/stephenharris/WordPressBehatExtension/jobs/171651680#L803 (the tests still pass because we're not running in strict mode - that should be changed I think).

[Chrico]

Done! thanks a lot for the notice. :)

[Chrico]

Meh, sry i messed things up with a4a256f - but i reverted everything in 8a9629d . The changes shouldn't be done here in this pull. I created a new issue #9 for this to handle the "duplicated" code.

[stephenharris]

Looks like there are three failing scenarios:

1. features/plugins.feature:34
2. features/user.feature:11
3. features/user.feature:25

(1) - the hello.php plug-in doesn't appear to be uninstallable (?).

For (2) and (3) I think you forgot to revert the changes to features/user.feature.

Separately, I noticed the error message is wrong: Password for user password incorrect - it should be Password for user admin incorrect (where admin should be the username of the user). I've opened #11 for this.

[Chrico]

Howdy!

Thanks.

The features/plugins.feature:34 was related to a wrong usage of is_uninstallable_plugin in WordPressPluginContext::thePluginIsNotUninstallable.

The features/user.feature should now work, let's see what travis says.

[stephenharris]

Tests are failing, but I think for reasons other than this PR:

• Seems to be related to Tests sometimes fail at the log-in stage. #10 https://travis-ci.org/stephenharris/WordPressBehatExtension/jobs/171934215#L777
• Not sure why this is failing though: https://travis-ci.org/stephenharris/WordPressBehatExtension/jobs/171934216#L765

Might need to run this locally to identify if that's anything to worry about.

[stephenharris]

I couldn't replicate those errors locally.

One thing I think I had failed to notice before, the functions are not really end-user tests, but are just testing the WP functions. For example:

Scenario: I activate just the dolly plugin
    Given I activate the plugin "hello.php"
    Then The plugin "hello.php" is activated

The Given step just calls the activate_plugin() function. Really it's a When step, and it ought to mimic the user selecting the plug-in and activating it via the admin interface. e.g.

Scenario: I activate just the dolly plugin
    Given I go to menu item "Plugins"
    When I activate the plugin "hello.php"
    Then The plugin "hello.php" is activated

Or it's Given step, and we are stating that the plug-in should already have been activate prior to us performing some When steps, e.g.:

Scenario: I activate just the dolly plugin
    Given the plugin "hello.php" is active
    When I do a, b, c
    Then I see x, y and z