Testing in Headless Browsers - The wasm-bindgen
Guide (original) (raw)
- Introduction
- 1. Examples
- 1.1. Hello, World!
- 1.2. Using console.log
- 1.3. Small Wasm files
- 1.4. Without a Bundler
- 1.5. Synchronous Instantiation
- 1.6. Importing functions from JS
- 1.7. Working with char
- 1.8. js-sys: WebAssembly in WebAssembly
- 1.9. web-sys: DOM hello world
- 1.10. web-sys: Closures
- 1.11. web-sys: performance.now
- 1.12. web-sys: using fetch
- 1.13. web-sys: Weather report
- 1.14. web-sys: canvas hello world
- 1.15. web-sys: canvas Julia set
- 1.16. web-sys: WebAudio
- 1.17. web-sys: WebGL
- 1.18. web-sys: WebSockets
- 1.19. web-sys: WebRTC DataChannel
- 1.20. web-sys: requestAnimationFrame
- 1.21. web-sys: A Simple Paint Program
- 1.22. web-sys: Wasm in Web Worker
- 1.23. Parallel Raytracing
- 1.24. Wasm Audio Worklet
- 1.25. web-sys: A TODO MVC App
- 2. Reference
- 2.1. Deployment
- 2.2. JS snippets
- 2.3. Static JS Objects
- 2.4. Passing Rust Closures to JS
- 2.5. Receiving JS Closures in Rust
- 2.6. Promises and Futures
- 2.7. Iterating over JS Values
- 2.8. Arbitrary Data with Serde
- 2.9. Accessing Properties of Untyped JS Values
- 2.10. Working with Duck-Typed Interfaces
- 2.11. Command Line Interface
- 2.12. Optimizing for Size
- 2.13. Supported Rust Targets
- 2.14. Supported Browsers
- 2.15. Support for Weak References
- 2.16. Support for Reference Types
- 2.17. Supported Types
- 2.18. #[wasm_bindgen] Attributes
- 2.18.1. On JavaScript Imports
- 2.18.1.1. catch
- 2.18.1.2. constructor
- 2.18.1.3. extends
- 2.18.1.4. getter and setter
- 2.18.1.5. final
- 2.18.1.6. indexing_getter, indexing_setter, and indexing_deleter
- 2.18.1.7. js_class = "Blah"
- 2.18.1.8. js_name
- 2.18.1.9. js_namespace
- 2.18.1.10. method
- 2.18.1.11. module = "blah"
- 2.18.1.12. raw_module = "blah"
- 2.18.1.13. no_deref
- 2.18.1.14. static_method_of = Blah
- 2.18.1.15. structural
- 2.18.1.16. typescript_type
- 2.18.1.17. variadic
- 2.18.1.18. vendor_prefix
- 2.18.1.1. catch
- 2.18.2. On Rust Exports
- 2.18.2.1. constructor
- 2.18.2.2. js_name = Blah
- 2.18.2.3. js_class = Blah
- 2.18.2.4. readonly
- 2.18.2.5. skip
- 2.18.2.6. skip_jsdoc
- 2.18.2.7. start
- 2.18.2.8. main
- 2.18.2.9. typescript_custom_section
- 2.18.2.10. getter and setter
- 2.18.2.11. inspectable
- 2.18.2.12. skip_typescript
- 2.18.2.13. getter_with_clone
- 2.18.2.14. unchecked_return_type and unchecked_param_type
- 2.18.2.15. return_description and param_description
- 2.18.2.1. constructor
- 3. web-sys
- 4. Testing with wasm-bindgen-test
- 5. Contributing to wasm-bindgen
- 5.2. Internal Design
- 5.3. js-sys
- 5.4. web-sys
- 5.5. Publishing
- 5.6. Team
The `wasm-bindgen` Guide
Testing in Headless Browsers Configure via Environment Variables
By default tests run on Node.js. To target browsers you can use the WASM_BINDGEN_USE_BROWSER
environment variable:
WASM_BINDGEN_USE_BROWSER=1 cargo test --target wasm32-unknown-unknown
The following configurations are available:
WASM_BINDGEN_USE_DEDICATED_WORKER
: for dedicated workersWASM_BINDGEN_USE_SHARED_WORKER
: for shared workersWASM_BINDGEN_USE_SERVICE_WORKER
: for service workersWASM_BINDGEN_USE_DENO
: for DenoWASM_BINDGEN_USE_NODE_EXPERIMENTAL
: for Node.js but as an ES module Force Configuration
Tests can also be forced to run in a certain environment by using thewasm_bindgen_test_configure!
macro:
# #![allow(unused_variables)]
#fn main() {
use wasm_bindgen_test::wasm_bindgen_test_configure;
// Run in a browser.
wasm_bindgen_test_configure!(run_in_browser);
// Or run in a dedicated worker.
wasm_bindgen_test_configure!(run_in_dedicated_worker);
// Or run in a shared worker.
wasm_bindgen_test_configure!(run_in_shared_worker);
// Or run in a service worker.
wasm_bindgen_test_configure!(run_in_service_worker);
// Or run in Node.js but as an ES module.
wasm_bindgen_test_configure!(run_in_node_experimental);
#}
Note that this will ignore any environment variable set.
Configuring Which Browser is Used
To control which browser is used for headless testing, use the appropriate flag with wasm-pack test
:
wasm-pack test --chrome
— Run the tests in Chrome. This machine must have Chrome installed.wasm-pack test --firefox
— Run the tests in Firefox. This machine must have Firefox installed.wasm-pack test --safari
— Run the tests in Safari. This machine must have Safari installed.
If multiple browser flags are passed, the tests will be run under each browser.
Running the Tests in the Headless Browser
Once the tests are configured to run in a headless browser, just run wasm-pack test
with the appropriate browser flags and --headless
:
wasm-pack test --headless --chrome --firefox --safari
Configuring Headless Browser capabilities
Add the file webdriver.json
to the root of your crate. Each browser has own section for capabilities. For example:
{
"moz:firefoxOptions": {
"prefs": {
"media.navigator.streams.fake": true,
"media.navigator.permission.disabled": true
},
"args": []
},
"goog:chromeOptions": {
"args": [
"--use-fake-device-for-media-stream",
"--use-fake-ui-for-media-stream"
]
}
}
Full list supported capabilities can be found:
Note that the headless
argument is always enabled for both browsers.
Debugging Headless Browser Tests
Omitting the --headless
flag will disable headless mode, and allow you to debug failing tests in your browser's devtools.
Appendix: Testing in headless browsers without wasm-pack
⚠️ The recommended way to use wasm-bindgen-test
is with wasm-pack
, since it will handle installing the test runner, installing a WebDriver client for your browser, and informing cargo
how to use the custom test runner. However, you can also manage those tasks yourself, if you wish.
Configuring Which Browser is Used
If one of the following environment variables is set, then the corresponding WebDriver and browser will be used. If none of these environment variables are set, then the $PATH
is searched for a suitable WebDriver implementation.
GECKODRIVER=path/to/geckodriver
Use Firefox for headless browser testing, and geckodriver
as its WebDriver.
The firefox
binary must be on your $PATH
.
CHROMEDRIVER=path/to/chromedriver
Use Chrome for headless browser testing, and chromedriver
as its WebDriver.
The chrome
binary must be on your $PATH
.
SAFARIDRIVER=path/to/safaridriver
Use Safari for headless browser testing, and safaridriver
as its WebDriver.
This is installed by default on Mac OS. It should be able to find your Safari installation by default.
Running the Tests in the Remote Headless Browser
Tests can be run on a remote webdriver. To do this, the above environment variables must be set as URL to the remote webdriver. For example:
CHROMEDRIVER_REMOTE=http://remote.host/
Running the Tests in the Headless Browser
Once the tests are configured to run in a headless browser and the appropriate environment variables are set, executing the tests for headless browsers is the same as executing them for Node.js:
cargo test --target wasm32-unknown-unknown
Debugging Headless Browser Tests
Set the NO_HEADLESS=1
environment variable and the browser tests will not run headless. Instead, the tests will start a local server that you can visit in your Web browser of choices, and headless testing should not be used. You can then use your browser's devtools to debug.