[tests-only][full-ci] use predefined users with web e2e tests

[nirajacharya2]

Description

With this PR, we can run selective tests using predefined users.

Tests that cannot be run (at least for now):

• admin action tests:
  • admin-settings
  • role assignment
  • any admin actions
• group tests

What happens when using predefined users?

• admin user will not create any users during the test
• after each scenario, user resources and settings will be reverted without trying to delete the user.

How to Run Tests

Available configs:

• PREDEFINED_USERS: (true|false)
• PREDEFINED_USERS_FILE: (path to a JSON file mapping predefined users)

Predefined users JSON file example:

Important

The user keys MUST be the defined ones only
Available keys:

{
 "alice": {//map user}, ❗MANDATORY
 "brian": {//map user}, ❗MANDATORY
 "carol": {//map user}, ❗MANDATORY
 "david": {//map user},
 "edith": {//map user},
 "max": {//map user},
}

Required user properties:

{
 "id": "<usernmae>",
 "displayName": "<display-name>",
 "password": "<password>",
 "email": "<email>"
}

Example mapping:

{
  "alice": {
    "id": "einstein",
    "displayName": "Albert Einstein",
    "password": "relativity",
    "email": "einstein@example.org"
  },
  "brian": {
    "id": "marie",
    "displayName": "Marie Skłodowska Curie",
    "password": "radioactivity",
    "email": "marie@example.org"
  },
  "carol": {
    "id": "moss",
    "displayName": "Maurice Moss",
    "password": "vista",
    "email": "moss@example.org"
  }
}

Note

Only the test scenarios tagged with @predefined-users work with predefined users.

Command:

PREDEFINED_USERS=true \
PREDEFINED_USERS_FILE='./users.json' \
pnpm test:e2e:cucumber tests/e2e/cucumber/features/smoke/upload.feature:63 --tags '@predefined-users'

Related Issue

• [QA] run tests with existing users #12425

Motivation and Context

To be able to run webUI e2e tests with pre-production servers

How Has This Been Tested?

• test environment: 🖥️

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests
• Documentation
• Maintenance (e.g. dependency updates or tooling)

[deyankiteworks]

Great work and LGTM.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud