rust/comprehensive-rust
1
0
Fork 0
mirror of https://github.com/google/comprehensive-rust.git synced 2025-12-21 06:31:06 +02:00
Code Issues Releases Activity
Files
7d4149ac7a8ccb4714a7eda32b579e2bc5c93075
comprehensive-rust/tests/README.md

49 lines
2.0 KiB
Markdown
Raw Normal View History

Add a test framework to test the JS part of the course (#2471) 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>
2024-12-04 10:06:58 +01:00
# Testing Comprehensive Rust
The course material contains JS code that can break and needs to be checked for
functionality. Examples are `theme/speaker-notes.js` or `theme/book.js`.
Comprehensive Rust is using [webdriverIO](https://webdriver.io/) and the
[webdriverIO Expect API](https://webdriver.io/docs/api/expect-webdriverio/) in
Fix link in README.md (#2705)
2025-04-01 10:18:36 +02:00
combination with [Mocha](https://mochajs.org/). WebdriverIO is taking care of
Add a test framework to test the JS part of the course (#2471) 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>
2024-12-04 10:06:58 +01:00
accessing the webpage with a real browser and can access the state of the page
so behavior can be asserted.
The [Static Server Service](https://webdriver.io/docs/static-server-service/) is
Fix build github workflow reference (#2843) ## PR Summary This small PR fixes the build github workflow reference in `tests/README.md`. --------- Signed-off-by: Emmanuel Ferdman <emmanuelferdman@gmail.com>
2025-08-08 14:55:14 +03:00
used mainly in the [CI](../.github/workflows/build.yml) to serve the book on
port `localhost:8080` such that the test runner can access it. This mode is used
when `npm start` or `npm test` is executed.
Add a test framework to test the JS part of the course (#2471) 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>
2024-12-04 10:06:58 +01:00
Add xtask command for running web-tests. (#2743) 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>
2025-05-07 12:31:08 +03:00
> **Tip:** Use `cargo xtask web-tests` to run the tests in this directory from
> anywhere in the repository.
Start a small playbook on how to deal with failing webtests. (#2962) 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
2025-10-30 09:14:21 +01:00
For local testing and quick iterations it is possible to use `cargo xtask serve`
Add a test framework to test the JS part of the course (#2471) 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>
2024-12-04 10:06:58 +01:00
which creates a small HTTP server on port 3000 by default. There is a special
config that is invoked with `npm run test-mdbook` that uses
`http://localhost:3000`
Start a small playbook on how to deal with failing webtests. (#2962) 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
2025-10-30 09:14:21 +01:00
## Deal with failing tests
When you see tests failing they should already indicate what checks broke for
specific pages.
### Legitimate warnings
You might e.g. need to reduce the length of an overlong page (or get an
exemption) or updating some mdbook infrastructure had a breaking change that
breaks functionality. These issues need to be fixed before this change is
merged.
### Broken test environment
Sometimes tests can also fail in the CI environment with errors like this.
```
ERROR webdriver: WebDriverError: tab crashed
```
If you see messages like these, it may indicate an issue with the web-tests that
is not caused by your changes. Please file a bug to report this. As a temporary
workaround, if all other checks pass and you are confident your changes are
correct, you may override the web-test requirement to merge your pull request.
Reference in New Issue Copy Permalink