E2E Test Utils – Hardcoded administrator user/password

[crs1138]

Description

The default administrator user used for E2E testing is hardcoded as user: admin and password: password in the config.js. This gets automatically used by the testing suite if the current user is anything else but admin as you can see in switchUserToAdmin() at switch-user-to-admin.js. The suite does not actually test whether the current user has administrators rights, instead it tests for the username being admin.

This seems a strange default setting, considering that WP does not let you, by default, create a user with username admin (unless you edit directly in database).

Step-by-step reproduction instructions

1. When running e2e tests, I try to activate a plugin…

    beforeAll(async () => {
        ...
        await activatePlugin('my-plugin');
        ...
    });

2. This fails as the WP_USERNAME supplied by process.env.WP_USERNAME is not admin.

Expected behaviour

Either:

1. Test for the WP_USERNAME having administrator's rights
2. Allow to use environment variables WP_ADMIN_USERNAME and WP_ADMIN_PASSWORD for administrator's login

Actual behaviour

Uses admin and password as the administrator's login details if the WP_USERNAME is not admin.

WordPress information

• WordPress version: 5.6.2
• Gutenberg version: 10.3.2
• Are all plugins except Gutenberg deactivated? Yes
• Are you using a default theme (e.g. Twenty Twenty-One)? Yes

Device information

• Device: Desktop
• Operating system: MacOS 11.2.3
• Browser: Chromium 88.0.4298.0 (Developer Build) (x86_64)

[gziolo]

https://github.com/WordPress/gutenberg/blob/trunk/docs/contributors/code/testing-overview.md#end-to-end-testing

Can you check with:

npm run test-e2e -- --wordpress-base-url=http://localhost:8888 --wordpress-username=admin --wordpress-password=password

[crs1138]

I can confirm that tests run correctly when using the wp-env environment. However, that is not useful in our case as we have no WP instance running on http://localhost:8888 and in our set up we need to be able to run the tests right after deployment to stage. It is impossible (for security reasons) to have a user admin with password password in our set up, as the stage environment takes on the authoritative db dump from production.