Closes #138: Make SCENARIO_URLS dynamic and depending on the running test

[Miraeld]

Description

Fixes #138
This PR introduces a change that allows scenario URLs to be loaded conditionally based on the current test being run. This improves the efficiency of our tests by only loading the URLs that are needed for each test, which can lead to faster test execution and less flakiness on poor internet connections

Type of change

• New feature (non-breaking change which adds functionality).
• Bug fix (non-breaking change which fixes an issue).
• Enhancement (non-breaking change which improves an existing functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as before).
• Sub-task of #(issue number)
• Release

Detailed scenario

To trigger the new code, simply run a test script. The scenario URLs for that specific test will be loaded from a JSON file and used in the test.

Technical description

Documentation

The code works by first importing a JSON file that maps script names to their respective scenario URLs. Then, in the wp.config.ts file, it retrieves the current script name using process.env.npm_lifecycle_event. This script name is used to look up the corresponding scenario URLs in the imported JSON object, and these URLs are assigned to SCENARIO_URLS.

New dependencies

No new dependencies were introduced in this change.

Risks

There are no known performance or security risks associated with this change. The main risk is that if the JSON file or the wp.config.ts file is not properly configured, the correct scenario URLs might not be loaded

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.).
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

[Mai-Saad]

@Miraeld @jeawhanlee Thanks for the PR. on PR running test:smoke will run backstop. can you please check 🙏

[jeawhanlee]

@Mai-Saad Do we have backstop references being created for urls with this PR, if not, I think we are good, what you mentioned will be fixed on a different issue here

[Mai-Saad]

Do we have backstop references being created for urls with this PR

yes
screen-capture - 2024-09-19T134110.947.webm

[Miraeld]

@Mai-Saad Have you modified your own wp.config.ts to include the change related to SCENARIO_URLS.
Because I don't get any reference for smoke tests, so I'm wondering ...

You should have something like :

import ScenarioUrls from './scenarioUrls.json';

// ... Rest of your config

const scriptName = process.env.npm_lifecycle_event;
const SCENARIO_URLS = ScenarioUrls[scriptName];

// ... Rest of your config

export {
    WP_USERNAME,
    WP_PASSWORD,
    WP_BASE_URL,
    WP_ROOT_DIR,
    WP_ENV_TYPE,
    WP_DOCKER_CONTAINER,
    WP_DOCKER_ROOT_DIR,
    WP_SSH_USERNAME,
    WP_SSH_ADDRESS,
    WP_SSH_KEY,
    WP_SSH_ROOT_DIR,
    SCENARIO_URLS
};

[Mai-Saad]

@Miraeld you are right, I was using the old config. updated the config and no references with smoke now 🙏 and with llcssbg references are created

[jeawhanlee]

I can confirm this as well.

[hanna-meda]

@Miraeld, @jeawhanlee, @Mai-Saad can confirm this, too.

Tested also with llimages, lcp, wpml for which no references will be created ✓

Backstop references will be created only for llcssbg ✓