You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document is designed to be a living record of the current and projected priorities for the WebdriverIO project. It is, of course, always subject to change and exists solely to give the community an idea of where we're going. The roadmap is set by the Technical Steering Committee (TSC) team. If you have feature suggestions for WebdriverIO or any of the @wdio packages, please submit a GitHub issue and, if of sufficient size and approved by the team, it will be added here. If you have concerns about the roadmap, you can raise a GitHub issue. Note that bugfixes and miscellaneous features are not considered "roadmap projects", and will be addressed in the due course of normal project development. This page exists to outline large-scale future plans for WebdriverIO.
There are already a handful options to debug test code with WebdriverIO. However it is still not straight forward to use native Node.js debugging capabilities which requires special handling of workers and sub processes. Goal has to be that developers can use their IDEs to set breakpoints to debug.
We got numerous of requests to allow to parallelize test on a block level and not file level. A possible option would be to add Ava as framework which comes with that kind of parallelization.
The @wdio/devtools-service provides automation capabilities beyond WebDriver (e.g. get network logs, tracing, performance etc). There is a variety of things that can be added to help people test their applications (e.g. better mocking/stubbing of browser requests and responses). Also it would be desire-able if the service would work in Firefox and Edge in the same way.
One of community members already started to build a fiddle (try.webdriver.io) for WebdriverIO. It is currently not working that well and needs more work. It would help tremendously to share test code snippets to identify issues in someones automation script. A Sauce Labs integration would also be possible here.
We want to make it seamless to assert network behavior of the browser. Inspired by Jest and their Snapshot functionality we can implement similar behavior in WebdriverIO.
Almost all web applications are written in either React, Angular, Vue, Svelte or a different frontend framework that allows you to ship modern web application today. These frameworks are often difficult to deal with when it comes to selecting elements or introspection of app states and important parts. WebdriverIO has the capabilities to help the user to test these applications better.
Currently WebdriverIO is only able to run in Node.js which is the environment that most users use it. However it would be nice to also enable WebdriverIO for other environment such as the browser or Deno. For this to happen, all packages need to be made ESM compatible.
Completed Roadmap Projects
Project
Description
Completed
WebdriverIO Release
Notes
Make CLI tool more powerful
Adding simple add ons to the setup becomes difficult if the person is not familiar with the project or WebDriver in general. Adding some simple commands to the CLI interface that allows to add service and reporters and modifies the config would make the process of adding plugins much easier.
A lot of people request support for Cucumber as it is their main framework choice. Initial work on this has already been done by the community. The code needs to get proper unit tests but would then be good to go.
Jest has become one of the most popular unit test framework in the JS ecosystem. Even though most of their features are not helpful in the e2e space there are some things (e.g. snapshot testing) that could help people writing better e2e tests. There has been some initial work done on this.
To make assertion on elements or other objects simpler across all frameworks it would be nice if WebdriverIO would come with an native assertion library (similar how Jest or Jasmine provide one) embedded into the testrunner.
Let's allow user to pre-setup an existing boilerplate so that they don't need to setup these files by themselves. The community has gathered a lot of useful boilerplate projects that we want to allow to act as baseline for the test setup using the configuration wizard or a new wdio command.
There are various of projects that help you to bootstrap a project from scratch (e.g. create-react-app). We should add WebdriverIO as e2e testing option in there which will help us to driver adoption.
As we have better cross browser support for Puppeteer we should move forward and provide better network primitives for WebdriverIO to help user access the network layer. In addition to that these features are likely to be supported once WebDriver moves to a BiDi protocol (which is a new version of WebDriver that is currently designed by the W3C working group and browser vendors).
As our code base is growing we are more impacted by type issues that are hard to detect. To avoid such problems and make the code base easier to work with we plan to rewrite it into TypeScript.