Merge pull request #190 from ernilambar/add-behat-file

Add missing behat.yml file and update feature tests
wp-cli · Jul 16, 2024 · a5ac769 · a5ac769
2 parents 017b02e + 792cdb1
commit a5ac769
Show file tree

Hide file tree

Showing 12 changed files with 165 additions and 44 deletions.
diff --git a/.github/workflows/testing.yml b/.github/workflows/testing.yml
@@ -12,3 +12,5 @@ on:
 jobs:
   test:
     uses: wp-cli/.github/.github/workflows/reusable-testing.yml@main
+    with:
+      minimum-wp: '4.8'
diff --git a/behat.yml b/behat.yml
@@ -0,0 +1,7 @@
+default:
+  suites:
+    default:
+      contexts:
+        - WP_CLI\Tests\Context\FeatureContext
+      paths:
+        - features
diff --git a/composer.json b/composer.json
@@ -31,7 +31,8 @@
         "process-timeout": 7200,
         "sort-packages": true,
         "allow-plugins": {
-            "dealerdirect/phpcodesniffer-composer-installer": true
+            "dealerdirect/phpcodesniffer-composer-installer": true,
+            "johnpbloch/wordpress-core-installer": true
         }
     },
     "extra": {

diff --git a/features/check-autoload-options-size.feature b/features/check-autoload-options-size.feature
@@ -22,6 +22,7 @@ Feature: Check the size of autoloaded options
       is less than threshold (900kb)
       """
 
+  @less-than-wp-6.5
   Scenario: Autoloaded options are greater than 900 kb
     Given a WP install
     And a explode-options.php file:

diff --git a/features/check-core-update.feature b/features/check-core-update.feature
@@ -10,38 +10,67 @@ Feature: Check whether WordPress is up to date
 
   Scenario: WordPress is up to date
     Given a WP install
+    And a setup.php file:
+      """
+      <?php
+      global $wp_version;
+
+      $obj = new stdClass;
+      $obj->updates = [];
+      $obj->last_checked = strtotime( '1 January 2099' );
+      $obj->version_checked = $wp_version;
+      $obj->translations = [];
+      set_site_transient( 'update_core', $obj );
+      """
+    And I run `wp eval-file setup.php`
 
     When I run `wp doctor check core-update`
     Then STDOUT should be a table containing rows:
       | name          | status  | message                                   |
       | core-update   | success | WordPress is at the latest version.       |
 
+  @require-wp-6.0 @require-php-7.0
   Scenario: WordPress has a new minor version but no new major version
     Given a WP install
-    And I run `wp core download --version=4.5.1 --force`
-    And I run `wp theme activate twentyfifteen`
+    And I run `wp theme delete --all --force`
+    And I run `wp theme install twentytwelve --activate`
+
+    When I run `(curl -s https://api.wordpress.org/core/version-check/1.7/ | jq -r ".offers[0].new_bundled" | cut -d '.' -f 1,2)`
+    Then save STDOUT as {LATEST_WP_VERSION}
+
+    When I run `wp core download --version={LATEST_WP_VERSION} --force`
+    Then STDOUT should contain:
+      """
+      Success: WordPress downloaded.
+      """
 
     When I try `wp doctor check core-update`
     Then STDOUT should be a table containing rows:
-      | name          | status  | message                                   |
+      | name          | status  | message                                                              |
       | core-update   | error   | Updating to WordPress' newest minor version is strongly recommended. |
     And STDERR should contain:
       """
       Error: 1 check reports 'error'.
       """
     And the return code should be 1
 
+  @require-mysql
   Scenario: WordPress has a new major version but no new minor version
     Given a WP install
-    And I run `wp core download --version=4.4.9 --force`
-    And I run `wp theme activate twentyfifteen`
+    And I run `wp theme delete --all --force`
+    And I run `wp theme install twentytwelve --activate`
+    And I run `wp core download --version=4.1.30 --force`
 
-    When I try `wp doctor check core-update`
-    Then STDOUT should be a table containing rows:
-      | name          | status  | message                                             |
-      | core-update   | error   | Updating to WordPress' newest minor version is strongly recommended. |
-    And STDERR should contain:
+    # This version of WP throws a PHP notice.
+    When I try `wp core update --minor`
+    Then STDOUT should contain:
       """
-      Error: 1 check reports 'error'.
+      Success: WordPress updated successfully.
       """
-    And the return code should be 1
+    And the return code should be 0
+
+    When I try `wp doctor check core-update`
+    Then STDOUT should be a table containing rows:
+      | name          | status  | message                                                   |
+      | core-update   | warning | A new major version of WordPress is available for update. |
+    And the return code should be 0
diff --git a/features/check-file-contents.feature b/features/check-file-contents.feature
@@ -16,9 +16,11 @@ Feature: Check files in a WordPress install
       | name          | status    | message                                                       |
       | file-eval     | success   | All 'php' files passed check for 'eval\(.*base64_decode\(.*'. |
 
-    Given a wp-content/mu-plugins/exploited.php file:
+    Given a wp-content/plugins/exploited.php file:
       """
       <?php
+      // Plugin Name: Example Plugin
+
       eval( base64_decode( $_POST ) );
       """
 

diff --git a/features/check-language-update.feature b/features/check-language-update.feature
@@ -16,28 +16,52 @@ Feature: Check whether languages are up to date
       | name            | status  | message                   |
       | language-update | success | Languages are up to date. |
 
-  Scenario: One language has an update available
-    Given a WP install
-      And a wp-content/languages/custom.po file:
-        """
-        # Translation of WordPress - 4.8.x in Japanese
-        # This file is distributed under the same license as the WordPress - 4.8.x package.
-        msgid ""
-        msgstr ""
-        "PO-Revision-Date: 2016-08-03 23:23:50+0000\n"
-        "MIME-Version: 1.0\n"
-        "Content-Type: text/plain; charset=UTF-8\n"
-        "Content-Transfer-Encoding: 8bit\n"
-        "Plural-Forms: nplurals=1; plural=0;\n"
-        "X-Generator: GlotPress/2.4.0-alpha\n"
-        "Language: ja_JP\n"
-        "Project-Id-Version: WordPress - 4.8.x\n"
-        """
-
-      When I run `wp language core install ja`
-      And I run `cat wp-content/languages/custom.po > wp-content/languages/ja.po`
-
-      When I run `wp doctor check language-update`
-      Then STDOUT should be a table containing rows:
-        | name            | status  | message                             |
-        | language-update | warning | 1 language has an update available. |
+  @require-php-5.6 @less-than-php-7.0
+  Scenario Outline: Two languages have updates available
+    Given an empty directory
+    And WP files
+    And a database
+    And I run `wp core download --version=<original> --force`
+    And wp-config.php
+    And I run `wp core install --url='localhost:8001' --title='Test' --admin_user=wpcli --admin_email=admin@example.com --admin_password=1`
+
+    When I run `wp language core list --fields=language,status,update`
+    Then STDOUT should be a table containing rows:
+      | language | status      | update    |
+      | ar       | uninstalled | none      |
+      | en_CA    | uninstalled | none      |
+      | en_US    | active      | none      |
+      | ja       | uninstalled | none      |
+
+    When I run `wp language core install en_CA ja`
+    Then the wp-content/languages/admin-en_CA.po file should exist
+    And the wp-content/languages/en_CA.po file should exist
+    And the wp-content/languages/admin-ja.po file should exist
+    And the wp-content/languages/ja.po file should exist
+    And STDOUT should contain:
+      """
+      Success: Installed 2 of 2 languages.
+      """
+    And STDERR should be empty
+
+    Given I try `wp core download --version=<update> --force`
+    Then the return code should be 0
+    And I run `wp core update-db`
+
+    When I run `wp language core list --fields=language,status,update`
+    Then STDOUT should be a table containing rows:
+      | language | status      | update    |
+      | ar       | uninstalled | none      |
+      | en_CA    | installed   | available |
+      | en_US    | active      | none      |
+      | ja       | installed   | available |
+
+    When I run `wp doctor check language-update`
+    Then STDOUT should be a table containing rows:
+      | name            | status  | message                             |
+      | language-update | warning | 2 languages have updates available. |
+
+    Examples:
+      | original | update |
+      | 4.8      | 4.9    |
+      | 4.0.1    | 4.2    |
diff --git a/features/check-plugin-active-count.feature b/features/check-plugin-active-count.feature
@@ -26,7 +26,7 @@ Feature: Check whether a high number of plugins are activated
         options:
           threshold_count: 3
       """
-    And I run `wp plugin install user-switching rewrite-rules-inspector`
+    And I run `wp plugin install debug-bar wp-author-widget`
     And I run `wp plugin activate --all`
 
     When I run `wp doctor check plugin-active-count --config=config.yml`

diff --git a/features/check-plugin-deactivated.feature b/features/check-plugin-deactivated.feature
@@ -10,7 +10,7 @@ Feature: Check whether a high percentage of plugins are deactivated
 
   Scenario: All plugins are activated
     Given a WP install
-    And I run `wp plugin install user-switching rewrite-rules-inspector`
+    And I run `wp plugin install debug-bar wp-author-widget`
     And I run `wp plugin activate --all`
 
     When I run `wp doctor check plugin-deactivated`
@@ -20,7 +20,7 @@ Feature: Check whether a high percentage of plugins are deactivated
 
   Scenario: Too many plugins are deactivated
     Given a WP install
-    And I run `wp plugin install user-switching rewrite-rules-inspector`
+    And I run `wp plugin install debug-bar wp-author-widget`
 
     When I run `wp doctor check plugin-deactivated`
     Then STDOUT should be a table containing rows:
@@ -36,7 +36,7 @@ Feature: Check whether a high percentage of plugins are deactivated
         options:
           threshold_percentage: 60
       """
-    And I run `wp plugin install user-switching rewrite-rules-inspector`
+    And I run `wp plugin install debug-bar wp-author-widget`
 
     When I run `wp doctor check plugin-deactivated --config=custom.yml`
     Then STDOUT should be a table containing rows:

diff --git a/features/check-theme-update.feature b/features/check-theme-update.feature
@@ -20,7 +20,7 @@ Feature: Check whether themes are up to date
   Scenario: One theme has an update available
     Given a WP install
     And I run `wp theme update --all`
-    And I run `wp theme install p2 --version=1.5.1`
+    And I run `wp theme install moina --version=1.1.2`
 
     When I run `wp doctor check theme-update`
     Then STDOUT should be a table containing rows:

diff --git a/features/check.feature b/features/check.feature
@@ -1,5 +1,7 @@
 Feature: Basic check usage
 
+  # Message "Updating to WordPress' newest minor version is strongly recommended." of type "error" appears.
+  @broken @require-mysql
   Scenario: Use --spotlight to focus on warnings and errors
     Given a WP install
     And I run `wp plugin activate --all`
@@ -27,6 +29,57 @@ Feature: Basic check usage
       []
       """
 
+  Scenario: Use --spotlight to view warnings and errors
+    Given a WP install
+    And I run `wp option update blog_public 0`
+    And a wp-content/plugins/foo.php file:
+      """
+      <?php
+      // Plugin Name: Foo Plugin
+
+      wp_cache_flush();
+      """
+
+    When I try `wp doctor check option-blog-public php-in-upload cache-flush --format=csv --fields=name,status`
+    Then STDOUT should be:
+      """
+      name,status
+      cache-flush,warning
+      option-blog-public,error
+      php-in-upload,success
+      """
+    And the return code should be 1
+
+    When I run `wp doctor check php-in-upload plugin-active-count --spotlight`
+    Then STDOUT should be:
+      """
+      Success: All 2 checks report 'success'.
+      """
+    And the return code should be 0
+
+    When I run `wp doctor check plugin-active-count --spotlight`
+    Then STDOUT should be:
+      """
+      Success: The check reports 'success'.
+      """
+    And the return code should be 0
+
+    When I try `wp doctor check option-blog-public php-in-upload cache-flush --spotlight --format=csv --fields=name,status`
+    Then STDOUT should be:
+      """
+      name,status
+      cache-flush,warning
+      option-blog-public,error
+      """
+    And the return code should be 1
+
+    When I run `wp doctor check php-in-upload --spotlight --format=json`
+    Then STDOUT should be:
+      """
+      []
+      """
+    And the return code should be 0
+
   Scenario: Error when no checks nor --all are provided
     Given a WP install
 

diff --git a/features/config.feature b/features/config.feature
@@ -159,6 +159,8 @@ Feature: Configure the Doctor
       constant-savequeries-falsy
       """
 
+  # Minimum requirement for Akismet is WP 5.8.
+  @require-wp-5.8
   Scenario: Use the 'require' attribute to require an arbitrary path
     Given a WP install
     And a config.yml file:
-Original file line number
+Diff line change
@@ Expand Up / @@ -12,3 +12,5 @@ on: @@
     jobs:
       test:
         uses: wp-cli/.github/.github/workflows/reusable-testing.yml@main
+        with:
+          minimum-wp: '4.8'