This is a starting point on how to deal with failures in the web-test
checks. They are supposed to warn for legitimate issues but if they
fail, they can be overridden.
The web-tests will be separated into its own job to better differentiate
if issues in building the English translation or web-testing the English
translation are happening
## PR Summary
This small PR fixes the build github workflow reference in
`tests/README.md`.
---------
Signed-off-by: Emmanuel Ferdman <emmanuelferdman@gmail.com>
Currently, to run the tests that are located in the `tests` directory
(the js tests), one has to navigate to the directory and run `npm test`
or `npm start`. We now have a way of automating such task execution
using the binary in the `xtask` directory. This pr makes use of this by
introducing a new command `cargo xtask web-tests` that can be run from
anywhere in the repo to run the tests in the `tests` directory.
---------
Co-authored-by: Eric Githinji <egithinji@google.com>
This is a first draft for a test framework for testing the JS part of
the book that is discussed in #2462
It is using [webdriverIO](https://webdriver.io/) and the webdriverIO
[Expect API](https://webdriver.io/docs/api/expect-webdriverio/) in
combination with [Mocha](https://mochajs.org/). WebdriverIO is taking
care of accessing the webpage with a real browser and can access the
state of the page so behavior can be asserted.
Currently only a small test for the speaker-notes implementation demos
the functionality.
The [Static Server
Service](https://webdriver.io/docs/static-server-service/) is used to
serve the book in a way that the test runner can access it.
A CI integration can look like https://webdriver.io/docs/githubactions/
and is implemented with a headless setup. In CI it uses the language
variable to set environment variable that configures where the built
book should be mounted from
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
