Enhancing WebDriverIO Integration: Access or use of `settings.env`

[andreasciamanna]

I am currently working on setting up WebDriverIO-based tests using Taurus. In the usual setup, the wdio.conf.js file contains the baseUrl property. However, I noticed that the examples provided in this repository do not include this property. I initially assumed that Taurus would inject this information (from a settings.env in the wdio.yml file), but upon further inspection, I found that no base URL is defined in the Taurus configuration files and that it is hard-coded in the test itself.

I referred to the documentation for guidance, but it does not seem to cover this use case. This has led me to question whether the integration with WebDriverIO was designed with extensibility in mind.

In my project, I rely on settings.env, which is locally defined in a separate settings.yml file and included in the main YAML file. In the CI environment, this file is dynamically generated. This settings.yml file serves as the single source of truth and enables me to run different sets of tests (e.g. Locust and K6) against the same site. My current task is to add WebDriverIO-based tests to the same project.

The current requirement to hard-code the base Url (or use other means, such as environment variables in the wide tests) adds complexity to my project. It necessitates a refactor to ensure that all project parts use the same data source (settings).

I propose that Taurus should support the use of ${SOME_ENV_VARIABLE} within the execution section of the Taurus configuration file. This would allow for the definition of properties like baseUrl directly in the Taurus configuration, enabling multiple WebDriverIO executors with different configurations, including different base URLs. Furthermore, Taurus would call wdio with the --baseUrl argument, eliminating the need for any injection in the wdio.conf.js file.

This enhancement would increase the flexibility and extensibility of Taurus. I look forward to your thoughts on this proposal.