WebdriverIO
This WebDriver testing example will use WebdriverIO, and its testing suite. It is expected to have Node.js already
installed, along with npm
or yarn
although the finished example project uses yarn
.
Create a Directory for the Tests
Let’s create a space to write these tests in our project. We will be using a nested directory for
this example project as we will later also go over other frameworks, but typically you only need to use one. Create
the directory we will use with mkdir -p webdriver/webdriverio
. The rest of this guide assumes you are inside the
webdriver/webdriverio
directory.
Initializing a WebdriverIO Project
We will be using a pre-existing package.json
to bootstrap this test suite because we have already chosen specific
WebdriverIO config options and want to showcase a simple working solution. The bottom of this section has a collapsed
guide on setting it up from scratch.
package.json
:
We have a script that runs a WebdriverIO config as a test suite exposed as the test
command. We also have various
dependencies added by the @wdio/cli
command when we first set it up. In short, these dependencies are for
the most simple setup using a local WebDriver runner, Mocha as the test framework, and a simple Spec Reporter.
Click me if you want to see how to set a project up from scratch
The CLI is interactive, and you may choose the tools to work with yourself. Note that you will likely diverge from the rest of the guide, and you need to set up the differences yourself.
Let’s add the WebdriverIO CLI to this npm project.
To then run the interactive config command to set up a WebdriverIO test suite, you can then run:
Config
You may have noticed that the test
script in our package.json
mentions a file wdio.conf.js
. That’s the WebdriverIO
config file which controls most aspects of our testing suite.
wdio.conf.js
:
If you are interested in the properties on the exports.config
object, I suggest reading the documentation.
For non-WDIO specific items, there are comments explaining why we are running commands in onPrepare
, beforeSession
,
and afterSession
. We also have our specs set to "./develop/tests/specs/**/*.js"
, so let’s create a spec now.
Spec
A spec contains the code that is testing your actual application. The test runner will load these specs and automatically run them as it sees fit. Let’s create our spec now in the directory we specified.
test/specs/example.e2e.js
:
The luma
function on top is just a helper function for one of our tests and is not related to the actual testing of
the application. If you are familiar with other testing frameworks, you may notice similar functions being exposed that
are used, such as describe
, it
, and expect
. The other APIs, such as items like $
and its exposed methods, are
covered by the WebdriverIO API docs.
Running the Test Suite
Now that we are all set up with config and a spec let’s run it!
We should see output the following output:
We see the Spec Reporter tell us that all 3 tests from the test/specs/example.e2e.js
file, along with the final report
Spec Files: 1 passed, 1 total (100% completed) in 00:00:01
.
Using the WebdriverIO test suite, we just easily enabled e2e testing for our Tauri application from just a few lines of configuration and a single command to run it! Even better, we didn’t have to modify the application at all.
© 2024 Tauri Contributors. CC-BY / MIT