From ba425d9264c6c4cb9a8c7e33ca02cb037462ae16 Mon Sep 17 00:00:00 2001
From: Alain Schlesser <alain.schlesser@gmail.com>
Date: Sat, 31 Oct 2026 13:55:36 +0100
Subject: [PATCH] Expect the configured test database name and user

Many scenarios expected the test database and its user to be called
wp_cli_test, which only holds with the default configuration, and not for
parallel test workers, which each use their own database.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 features/db-check.feature  | 14 ++++----
 features/db-export.feature | 56 ++++++++++++++---------------
 features/db-import.feature | 72 +++++++++++++++++++-------------------
 features/db-query.feature  |  6 ++--
 features/db-size.feature   | 14 ++++----
 features/db.feature        | 12 +++----
 6 files changed, 87 insertions(+), 87 deletions(-)

diff --git a/features/db-check.feature b/features/db-check.feature
index 744219ead..30986dfd5 100644
--- a/features/db-check.feature
+++ b/features/db-check.feature
@@ -7,7 +7,7 @@ Feature: Check the database
     When I run `wp db check`
     Then STDOUT should contain:
       """
-      wp_cli_test.wp_users
+      {DB_NAME}.wp_users
       """
     And STDOUT should contain:
       """
@@ -28,7 +28,7 @@ Feature: Check the database
     When I run `wp db check --silent`
     Then STDOUT should not contain:
       """
-      wp_cli_test.wp_users
+      {DB_NAME}.wp_users
       """
     And STDOUT should contain:
       """
@@ -42,7 +42,7 @@ Feature: Check the database
     When I run `wp db check --defaults`
     Then STDOUT should contain:
       """
-      wp_cli_test.wp_users
+      {DB_NAME}.wp_users
       """
     And STDOUT should contain:
       """
@@ -56,7 +56,7 @@ Feature: Check the database
     When I run `wp db check --no-defaults`
     Then STDOUT should contain:
       """
-      wp_cli_test.wp_users
+      {DB_NAME}.wp_users
       """
     And STDOUT should contain:
       """
@@ -67,7 +67,7 @@ Feature: Check the database
   Scenario: Run db check with passed-in options
     Given a WP install
 
-    When I run `wp db check --dbuser=wp_cli_test`
+    When I run `wp db check --dbuser={DB_USER}`
     Then STDOUT should contain:
       """
       Success: Database checked.
@@ -79,7 +79,7 @@ Feature: Check the database
       Success: Database checked.
       """
 
-    When I run `wp db check --dbuser=wp_cli_test --dbpass=password1`
+    When I run `wp db check --dbuser={DB_USER} --dbpass=password1`
     Then STDOUT should contain:
       """
       Success: Database checked.
@@ -101,7 +101,7 @@ Feature: Check the database
       """
     And STDOUT should be empty
 
-    When I try `wp db check --dbuser=wp_cli_test --verbose`
+    When I try `wp db check --dbuser={DB_USER} --verbose`
     Then the return code should be 0
     And STDOUT should contain:
       """
diff --git a/features/db-export.feature b/features/db-export.feature
index 6303f6087..910613575 100644
--- a/features/db-export.feature
+++ b/features/db-export.feature
@@ -6,59 +6,59 @@ Feature: Export a WordPress database
     When I run `wp db export --porcelain`
     Then STDOUT should contain:
       """
-      wp_cli_test-
+      {DB_NAME}-
       """
-    And the wp_cli_test.sql file should not exist
+    And the {DB_NAME}.sql file should not exist
 
   Scenario: Database export to a specified file path
     Given a WP install
 
-    When I run `wp db export wp_cli_test.sql --porcelain`
+    When I run `wp db export {DB_NAME}.sql --porcelain`
     Then STDOUT should contain:
       """
-      wp_cli_test.sql
+      {DB_NAME}.sql
       """
-    And the wp_cli_test.sql file should exist
+    And the {DB_NAME}.sql file should exist
 
   @skip-sqlite
   Scenario: Exclude tables when exporting the database
     Given a WP install
 
-    When I try `wp db export wp_cli_test.sql --exclude_tables=wp_users --porcelain`
-    Then the wp_cli_test.sql file should exist
-    And the contents of the wp_cli_test.sql file should not match /CREATE TABLE ["`]?wp_users["`]?/
-    And the contents of the wp_cli_test.sql file should match /CREATE TABLE ["`]?wp_options["`]?/
+    When I try `wp db export {DB_NAME}.sql --exclude_tables=wp_users --porcelain`
+    Then the {DB_NAME}.sql file should exist
+    And the contents of the {DB_NAME}.sql file should not match /CREATE TABLE ["`]?wp_users["`]?/
+    And the contents of the {DB_NAME}.sql file should match /CREATE TABLE ["`]?wp_options["`]?/
 
   @skip-sqlite
   Scenario: Include only specific tables when exporting the database
     Given a WP install
 
-    When I try `wp db export wp_cli_test.sql --tables=wp_users --porcelain`
-    Then the wp_cli_test.sql file should exist
-    And the contents of the wp_cli_test.sql file should match /CREATE TABLE ["`]?wp_users["`]?/
-    And the contents of the wp_cli_test.sql file should not match /CREATE TABLE ["`]?wp_posts["`]?/
-    And the contents of the wp_cli_test.sql file should not match /CREATE TABLE ["`]?wp_options["`]?/
+    When I try `wp db export {DB_NAME}.sql --tables=wp_users --porcelain`
+    Then the {DB_NAME}.sql file should exist
+    And the contents of the {DB_NAME}.sql file should match /CREATE TABLE ["`]?wp_users["`]?/
+    And the contents of the {DB_NAME}.sql file should not match /CREATE TABLE ["`]?wp_posts["`]?/
+    And the contents of the {DB_NAME}.sql file should not match /CREATE TABLE ["`]?wp_options["`]?/
 
   @require-sqlite
   Scenario: Exclude tables when exporting the database
     Given a WP install
 
-    When I try `wp db export wp_cli_test.sql --exclude_tables=wp_users --porcelain`
-    Then the wp_cli_test.sql file should exist
-    And the contents of the wp_cli_test.sql file should not match /_mysql_data_types_cache/
-    And the contents of the wp_cli_test.sql file should not match /CREATE TABLE ["`]?wp_users["`]?/
-    And the contents of the wp_cli_test.sql file should match /CREATE TABLE ["`]?wp_options["`]?/
+    When I try `wp db export {DB_NAME}.sql --exclude_tables=wp_users --porcelain`
+    Then the {DB_NAME}.sql file should exist
+    And the contents of the {DB_NAME}.sql file should not match /_mysql_data_types_cache/
+    And the contents of the {DB_NAME}.sql file should not match /CREATE TABLE ["`]?wp_users["`]?/
+    And the contents of the {DB_NAME}.sql file should match /CREATE TABLE ["`]?wp_options["`]?/
 
   @require-sqlite
   Scenario: Include only specific tables when exporting the database
     Given a WP install
 
-    When I try `wp db export wp_cli_test.sql --tables=wp_users --porcelain`
-    Then the wp_cli_test.sql file should exist
-    And the contents of the wp_cli_test.sql file should not match /_mysql_data_types_cache/
-    And the contents of the wp_cli_test.sql file should match /CREATE TABLE ["`]?wp_users["`]?/
-    And the contents of the wp_cli_test.sql file should not match /CREATE TABLE ["`]?wp_posts["`]?/
-    And the contents of the wp_cli_test.sql file should not match /CREATE TABLE ["`]?wp_options["`]?/
+    When I try `wp db export {DB_NAME}.sql --tables=wp_users --porcelain`
+    Then the {DB_NAME}.sql file should exist
+    And the contents of the {DB_NAME}.sql file should not match /_mysql_data_types_cache/
+    And the contents of the {DB_NAME}.sql file should match /CREATE TABLE ["`]?wp_users["`]?/
+    And the contents of the {DB_NAME}.sql file should not match /CREATE TABLE ["`]?wp_posts["`]?/
+    And the contents of the {DB_NAME}.sql file should not match /CREATE TABLE ["`]?wp_options["`]?/
 
   @require-sqlite
   Scenario: Export database to STDOUT
@@ -153,10 +153,10 @@ Feature: Export a WordPress database
   Scenario: Export database when PHP exec() is disabled
     Given a WP install
 
-    When I try `{INVOKE_WP_CLI_WITH_PHP_ARGS--ddisable_functions=exec} db export wp_cli_test.sql --porcelain`
+    When I try `{INVOKE_WP_CLI_WITH_PHP_ARGS--ddisable_functions=exec} db export {DB_NAME}.sql --porcelain`
     Then the return code should be 0
     And STDOUT should contain:
       """
-      wp_cli_test.sql
+      {DB_NAME}.sql
       """
-    And the wp_cli_test.sql file should exist
+    And the {DB_NAME}.sql file should exist
diff --git a/features/db-import.feature b/features/db-import.feature
index 1c9c324d7..dcfb3a47d 100644
--- a/features/db-import.feature
+++ b/features/db-import.feature
@@ -3,37 +3,37 @@ Feature: Import a WordPress database
   Scenario: Import from database name path by default
     Given a WP install
 
-    When I run `wp db export wp_cli_test.sql`
-    Then the wp_cli_test.sql file should exist
+    When I run `wp db export {DB_NAME}.sql`
+    Then the {DB_NAME}.sql file should exist
 
     When I run `wp db import`
     Then STDOUT should be:
       """
-      Success: Imported from 'wp_cli_test.sql'.
+      Success: Imported from '{DB_NAME}.sql'.
       """
 
   Scenario: Import from database name path by default with mysql defaults
     Given a WP install
 
-    When I run `wp db export wp_cli_test.sql`
-    Then the wp_cli_test.sql file should exist
+    When I run `wp db export {DB_NAME}.sql`
+    Then the {DB_NAME}.sql file should exist
 
     When I run `wp db import --defaults`
     Then STDOUT should be:
       """
-      Success: Imported from 'wp_cli_test.sql'.
+      Success: Imported from '{DB_NAME}.sql'.
       """
 
   Scenario: Import from database name path by default with --no-defaults
     Given a WP install
 
-    When I run `wp db export wp_cli_test.sql`
-    Then the wp_cli_test.sql file should exist
+    When I run `wp db export {DB_NAME}.sql`
+    Then the {DB_NAME}.sql file should exist
 
     When I run `wp db import --no-defaults`
     Then STDOUT should be:
       """
-      Success: Imported from 'wp_cli_test.sql'.
+      Success: Imported from '{DB_NAME}.sql'.
       """
 
   @require-mysql-or-mariadb
@@ -60,13 +60,13 @@ Feature: Import a WordPress database
   Scenario: Import from database name path by default and skip speed optimization
     Given a WP install
 
-    When I run `wp db export wp_cli_test.sql`
-    Then the wp_cli_test.sql file should exist
+    When I run `wp db export {DB_NAME}.sql`
+    Then the {DB_NAME}.sql file should exist
 
     When I run `wp db import --skip-optimization`
     Then STDOUT should be:
       """
-      Success: Imported from 'wp_cli_test.sql'.
+      Success: Imported from '{DB_NAME}.sql'.
       """
 
   # SQLite doesn't support the --dbuser flag.
@@ -74,16 +74,16 @@ Feature: Import a WordPress database
   Scenario: Import from database name path by default with passed-in dbuser/dbpass
     Given a WP install
 
-    When I run `wp db export wp_cli_test.sql`
-    Then the wp_cli_test.sql file should exist
+    When I run `wp db export {DB_NAME}.sql`
+    Then the {DB_NAME}.sql file should exist
 
-    When I run `wp db import --dbuser=wp_cli_test --dbpass=password1`
+    When I run `wp db import --dbuser={DB_USER} --dbpass=password1`
     Then STDOUT should be:
       """
-      Success: Imported from 'wp_cli_test.sql'.
+      Success: Imported from '{DB_NAME}.sql'.
       """
 
-    When I try `wp db import --dbuser=wp_cli_test --dbpass=no_such_pass`
+    When I try `wp db import --dbuser={DB_USER} --dbpass=no_such_pass`
     Then the return code should not be 0
     And STDERR should contain:
       """
@@ -116,10 +116,10 @@ Feature: Import a WordPress database
   Scenario: Import forwards the --ssl flag to the MySQL client
     Given a WP install
 
-    When I run `wp db export wp_cli_test.sql`
-    Then the wp_cli_test.sql file should exist
+    When I run `wp db export {DB_NAME}.sql`
+    Then the {DB_NAME}.sql file should exist
 
-    When I try `wp db import wp_cli_test.sql --ssl --debug`
+    When I try `wp db import {DB_NAME}.sql --ssl --debug`
     Then STDERR should contain:
       """
       --ssl
@@ -170,8 +170,8 @@ Feature: Import a WordPress database
   Scenario: MySQL defaults are available as appropriate with --defaults flag
     Given a WP install
 
-    When I run `wp db export wp_cli_test.sql`
-    Then the wp_cli_test.sql file should exist
+    When I run `wp db export {DB_NAME}.sql`
+    Then the {DB_NAME}.sql file should exist
 
     When I try `wp db import --defaults --debug`
     Then STDERR should match #Debug \(db\): Running shell command: /([^/]+/)+(mysql|mariadb) --no-auto-rehash#
@@ -194,9 +194,9 @@ Feature: Import a WordPress database
       🍣
       """
 
-    When I try `wp db export wp_cli_test.sql --debug`
+    When I try `wp db export {DB_NAME}.sql --debug`
     Then the return code should be 0
-    And the wp_cli_test.sql file should exist
+    And the {DB_NAME}.sql file should exist
     And STDERR should contain:
       """
       Detected character set of the posts table: utf8mb4
@@ -206,10 +206,10 @@ Feature: Import a WordPress database
       Setting missing default character set to utf8mb4
       """
 
-    When I run `wp db import --dbuser=wp_cli_test --dbpass=password1`
+    When I run `wp db import --dbuser={DB_USER} --dbpass=password1`
     Then STDOUT should be:
       """
-      Success: Imported from 'wp_cli_test.sql'.
+      Success: Imported from '{DB_NAME}.sql'.
       """
 
     When I run `wp post list`
@@ -231,14 +231,14 @@ Feature: Import a WordPress database
       🍣
       """
 
-    When I try `wp db export wp_cli_test.sql --debug`
+    When I try `wp db export {DB_NAME}.sql --debug`
     Then the return code should be 0
-    And the wp_cli_test.sql file should exist
+    And the {DB_NAME}.sql file should exist
 
-    When I run `wp db import --dbuser=wp_cli_test --dbpass=password1`
+    When I run `wp db import --dbuser={DB_USER} --dbpass=password1`
     Then STDOUT should be:
       """
-      Success: Imported from 'wp_cli_test.sql'.
+      Success: Imported from '{DB_NAME}.sql'.
       """
 
     When I run `wp post list`
@@ -316,14 +316,14 @@ Feature: Import a WordPress database
   Scenario: `wp db import` adapts the SQL mode via --init-command by default
     Given a WP install
 
-    When I run `wp db export wp_cli_test.sql`
-    Then the wp_cli_test.sql file should exist
+    When I run `wp db export {DB_NAME}.sql`
+    Then the {DB_NAME}.sql file should exist
 
     # The WordPress-compatibility mode adaptation runs on the same import
     # connection via --init-command, so it is visible in the debug output and no
     # separate mode probe runs (which is what used to break with custom connection
     # options).
-    When I try `wp db import wp_cli_test.sql --debug`
+    When I try `wp db import {DB_NAME}.sql --debug`
     Then the return code should be 0
     And STDERR should contain:
       """
@@ -338,10 +338,10 @@ Feature: Import a WordPress database
   Scenario: `wp db import --skip-sql-mode-compat` imports under the server's own SQL modes
     Given a WP install
 
-    When I run `wp db export wp_cli_test.sql`
-    Then the wp_cli_test.sql file should exist
+    When I run `wp db export {DB_NAME}.sql`
+    Then the {DB_NAME}.sql file should exist
 
-    When I try `wp db import wp_cli_test.sql --skip-sql-mode-compat --debug`
+    When I try `wp db import {DB_NAME}.sql --skip-sql-mode-compat --debug`
     Then the return code should be 0
     And STDERR should not contain:
       """
diff --git a/features/db-query.feature b/features/db-query.feature
index 6876593cf..ccbff1aca 100644
--- a/features/db-query.feature
+++ b/features/db-query.feature
@@ -26,7 +26,7 @@ Feature: Query the database with WordPress' MySQL config
   Scenario: Database querying with passed-in options
     Given a WP install
 
-    When I run `wp db query "SELECT COUNT(ID) FROM wp_posts;" --dbuser=wp_cli_test --html`
+    When I run `wp db query "SELECT COUNT(ID) FROM wp_posts;" --dbuser={DB_USER} --html`
     Then STDOUT should contain:
       """
       <TABLE
@@ -45,7 +45,7 @@ Feature: Query the database with WordPress' MySQL config
   Scenario: Database querying with MySQL defaults and passed-in options
     Given a WP install
 
-    When I run `wp db query --defaults "SELECT COUNT(ID) FROM wp_posts;" --dbuser=wp_cli_test --html`
+    When I run `wp db query --defaults "SELECT COUNT(ID) FROM wp_posts;" --dbuser={DB_USER} --html`
     Then STDOUT should contain:
       """
       <TABLE
@@ -64,7 +64,7 @@ Feature: Query the database with WordPress' MySQL config
   Scenario: Database querying with --nodefaults and passed-in options
     Given a WP install
 
-    When I run `wp db query --no-defaults "SELECT COUNT(ID) FROM wp_posts;" --dbuser=wp_cli_test --html`
+    When I run `wp db query --no-defaults "SELECT COUNT(ID) FROM wp_posts;" --dbuser={DB_USER} --html`
     Then STDOUT should contain:
       """
       <TABLE
diff --git a/features/db-size.feature b/features/db-size.feature
index 17f0d687b..f39961087 100644
--- a/features/db-size.feature
+++ b/features/db-size.feature
@@ -1,4 +1,4 @@
-# Assumes wp_cli_test has a database size of around 655,360 bytes.
+# Assumes {DB_NAME} has a database size of around 655,360 bytes.
 
 Feature: Display database size
 
@@ -9,7 +9,7 @@ Feature: Display database size
     When I run `wp db size`
     Then STDOUT should contain:
       """
-      wp_cli_test
+      {DB_NAME}
       """
 
     And STDOUT should contain:
@@ -42,7 +42,7 @@ Feature: Display database size
 
     But STDOUT should not contain:
       """
-      wp_cli_test
+      {DB_NAME}
       """
 
   @require-mysql-or-mariadb
@@ -52,7 +52,7 @@ Feature: Display database size
     When I run `wp db size --human-readable`
     Then STDOUT should contain:
       """
-      wp_cli_test
+      {DB_NAME}
       """
 
     And STDOUT should contain:
@@ -101,7 +101,7 @@ Feature: Display database size
 
     But STDOUT should not contain:
       """
-      wp_cli_test
+      {DB_NAME}
       """
 
     When I try `wp db size --tables --human-readable --size_format=b`
@@ -199,7 +199,7 @@ Feature: Display database size
     Then STDOUT should contain:
       """
       Name,Size
-      wp_cli_test,"
+      {DB_NAME},"
       """
 
     But STDOUT should not be a number
@@ -207,7 +207,7 @@ Feature: Display database size
     When I run `wp db size --size_format=b --format=json`
     Then STDOUT should contain:
       """
-      [{"Name":"wp_cli_test","Size":"
+      [{"Name":"{DB_NAME}","Size":"
       """
 
     But STDOUT should not be a number
diff --git a/features/db.feature b/features/db.feature
index 07656dcb0..499c16b00 100644
--- a/features/db.feature
+++ b/features/db.feature
@@ -44,13 +44,13 @@ Feature: Perform database operations
     # Check for contains only, as the string contains a trailing space.
     Then STDOUT should contain:
       """
-      Are you sure you want to drop the 'wp_cli_test' database? [y/n]
+      Are you sure you want to drop the '{DB_NAME}' database? [y/n]
       """
 
     When I run `wp db reset < session_yes`
     Then STDOUT should be:
       """
-      Are you sure you want to reset the 'wp_cli_test' database? [y/n] Success: Database reset.
+      Are you sure you want to reset the '{DB_NAME}' database? [y/n] Success: Database reset.
       """
 
   @skip-sqlite
@@ -67,7 +67,7 @@ Feature: Perform database operations
       (which means your username and password is okay)
       """
 
-    When I run `wp db create --dbuser=wp_cli_test`
+    When I run `wp db create --dbuser={DB_USER}`
     Then STDOUT should be:
       """
       Success: Database created.
@@ -95,7 +95,7 @@ Feature: Perform database operations
       """
     And STDOUT should be empty
 
-    When I run `wp db reset --yes --dbuser=wp_cli_test --dbpass=password1`
+    When I run `wp db reset --yes --dbuser={DB_USER} --dbpass=password1`
     Then STDOUT should be:
       """
       Success: Database reset.
@@ -117,7 +117,7 @@ Feature: Perform database operations
     Then STDOUT should be empty
     And the return code should be 0
 
-    When I run `wp db clean --yes --dbuser=wp_cli_test --dbpass=password1`
+    When I run `wp db clean --yes --dbuser={DB_USER} --dbpass=password1`
     Then STDOUT should be:
       """
       Success: Tables dropped.
@@ -155,7 +155,7 @@ Feature: Perform database operations
   Scenario: DB Operations with passed-in options
     Given a WP install
 
-    When I run `wp db optimize --dbuser=wp_cli_test`
+    When I run `wp db optimize --dbuser={DB_USER}`
     Then STDOUT should not be empty
 
     When I try `wp db optimize --dbuser=no_such_user`