fluencelabs/wasm-bindgen
1
0
Fork 0
mirror of https://github.com/fluencelabs/wasm-bindgen synced 2025-06-10 11:31:22 +00:00
Code Issues Projects Releases Wiki Activity
Files
82b322a12f125b17a455b8841f98c3ca8e1fce93
wasm-bindgen/crates/cli/src/bin/wasm-bindgen-test-runner/index-headless.html

39 lines
1.2 KiB
HTML
Raw Normal View History

Add support for headless testing This commit adds support to the `wasm-bindgen-test-runner` binary to perform headless testing via browsers. The previous commit introduced a local server to serve up files and run tests in a browser, and this commit adds support for executing that in an automated fashion. The general idea here is that each browser has a binary that implements the WebDriver specification. These binaries (typically `foodriver` for the browser "Foo") are interfaced with using HTTP and JSON messages. The implementation was simple enough and the crates.io support was lacking enough that a small implementation of the WebDriver protocol was added directly to this crate. Currently Firefox (`geckodriver`), Chrome (`chromedriver`), and Safari (`safaridriver`) are supported for running tests. The test harness will recognize env vars like `GECKODRIVER=foo` to specifically use one or otherwise detects the first driver in `PATH`. Eventually we may wish to automatically download a driver if one isn't found, but that isn't implemented yet. Headless testing is turned on with the `CI=1` env var currently to be amenable with things like Travis and AppVeyor, but this may wish to grow an explicit option to run headless tests in the future.
2018-07-25 03:34:35 -07:00
<html>
<head>
<meta content="text/html;charset=utf-8" http-equiv="Content-Type"/>
</head>
<body>
<pre id='output'>Loading scripts...</pre>
<pre id='console_log'></pre>
<pre id='console_error'></pre>
<script>
const orig_console_log = function(...args) {
const logs = document.getElementById('console_log');
for (let msg of args) {
logs.innerHTML += `${msg}\n`;
}
};
const orig_console_error = function(...args) {
const logs = document.getElementById('console_error');
for (let msg of args) {
logs.innerHTML += `${msg}\n`;
}
};
Use splat instead of `arguments` in tests Previously `arguments` was used to pass around an array of arguments, but this wasn't actually a `js_sys::Array` but rather a somewhat esoteric internal object. When switching over `Array` methods to be `structural` this caused issues because the inherent methods on an `arguments` object were different than that of `js_sys::Array`.
2018-11-08 11:46:52 -08:00
console.log = function(...args) {
Support asynchronous tests (#600) * Tweak the implementation of heap closures This commit updates the implementation of the `Closure` type to internally store an `Rc` and be suitable for dropping a `Closure` during the execution of the closure. This is currently needed for promises but may be generally useful as well! * Support asynchronous tests This commit adds support for executing tests asynchronously. This is modeled by tests returning a `Future` instead of simply executing inline, and is signified with `#[wasm_bindgen_test(async)]`. Support for this is added through a new `wasm-bindgen-futures` crate which is a binding between the `futures` crate and JS `Promise` objects. Lots more details can be found in the details of the commit, but one of the end results is that the `web-sys` tests are now entirely contained in the same test suite and don't need `npm install` to be run to execute them! * Review tweaks * Add some bindings for `Function.call` to `js_sys` Name them `call0`, `call1`, `call2`, ... for the number of arguments being passed. * Use oneshots channels with `JsFuture` It did indeed clean up the implementation!
2018-08-01 15:52:24 -05:00
if (window.console_log_redirect)
Use splat instead of `arguments` in tests Previously `arguments` was used to pass around an array of arguments, but this wasn't actually a `js_sys::Array` but rather a somewhat esoteric internal object. When switching over `Array` methods to be `structural` this caused issues because the inherent methods on an `arguments` object were different than that of `js_sys::Array`.
2018-11-08 11:46:52 -08:00
window.console_log_redirect(orig_console_log, args);
Add support for headless testing This commit adds support to the `wasm-bindgen-test-runner` binary to perform headless testing via browsers. The previous commit introduced a local server to serve up files and run tests in a browser, and this commit adds support for executing that in an automated fashion. The general idea here is that each browser has a binary that implements the WebDriver specification. These binaries (typically `foodriver` for the browser "Foo") are interfaced with using HTTP and JSON messages. The implementation was simple enough and the crates.io support was lacking enough that a small implementation of the WebDriver protocol was added directly to this crate. Currently Firefox (`geckodriver`), Chrome (`chromedriver`), and Safari (`safaridriver`) are supported for running tests. The test harness will recognize env vars like `GECKODRIVER=foo` to specifically use one or otherwise detects the first driver in `PATH`. Eventually we may wish to automatically download a driver if one isn't found, but that isn't implemented yet. Headless testing is turned on with the `CI=1` env var currently to be amenable with things like Travis and AppVeyor, but this may wish to grow an explicit option to run headless tests in the future.
2018-07-25 03:34:35 -07:00
else
Use splat instead of `arguments` in tests Previously `arguments` was used to pass around an array of arguments, but this wasn't actually a `js_sys::Array` but rather a somewhat esoteric internal object. When switching over `Array` methods to be `structural` this caused issues because the inherent methods on an `arguments` object were different than that of `js_sys::Array`.
2018-11-08 11:46:52 -08:00
orig_console_log.apply(this, args);
Add support for headless testing This commit adds support to the `wasm-bindgen-test-runner` binary to perform headless testing via browsers. The previous commit introduced a local server to serve up files and run tests in a browser, and this commit adds support for executing that in an automated fashion. The general idea here is that each browser has a binary that implements the WebDriver specification. These binaries (typically `foodriver` for the browser "Foo") are interfaced with using HTTP and JSON messages. The implementation was simple enough and the crates.io support was lacking enough that a small implementation of the WebDriver protocol was added directly to this crate. Currently Firefox (`geckodriver`), Chrome (`chromedriver`), and Safari (`safaridriver`) are supported for running tests. The test harness will recognize env vars like `GECKODRIVER=foo` to specifically use one or otherwise detects the first driver in `PATH`. Eventually we may wish to automatically download a driver if one isn't found, but that isn't implemented yet. Headless testing is turned on with the `CI=1` env var currently to be amenable with things like Travis and AppVeyor, but this may wish to grow an explicit option to run headless tests in the future.
2018-07-25 03:34:35 -07:00
};
Use splat instead of `arguments` in tests Previously `arguments` was used to pass around an array of arguments, but this wasn't actually a `js_sys::Array` but rather a somewhat esoteric internal object. When switching over `Array` methods to be `structural` this caused issues because the inherent methods on an `arguments` object were different than that of `js_sys::Array`.
2018-11-08 11:46:52 -08:00
console.error = function(...args) {
Support asynchronous tests (#600) * Tweak the implementation of heap closures This commit updates the implementation of the `Closure` type to internally store an `Rc` and be suitable for dropping a `Closure` during the execution of the closure. This is currently needed for promises but may be generally useful as well! * Support asynchronous tests This commit adds support for executing tests asynchronously. This is modeled by tests returning a `Future` instead of simply executing inline, and is signified with `#[wasm_bindgen_test(async)]`. Support for this is added through a new `wasm-bindgen-futures` crate which is a binding between the `futures` crate and JS `Promise` objects. Lots more details can be found in the details of the commit, but one of the end results is that the `web-sys` tests are now entirely contained in the same test suite and don't need `npm install` to be run to execute them! * Review tweaks * Add some bindings for `Function.call` to `js_sys` Name them `call0`, `call1`, `call2`, ... for the number of arguments being passed. * Use oneshots channels with `JsFuture` It did indeed clean up the implementation!
2018-08-01 15:52:24 -05:00
if (window.console_error_redirect)
Use splat instead of `arguments` in tests Previously `arguments` was used to pass around an array of arguments, but this wasn't actually a `js_sys::Array` but rather a somewhat esoteric internal object. When switching over `Array` methods to be `structural` this caused issues because the inherent methods on an `arguments` object were different than that of `js_sys::Array`.
2018-11-08 11:46:52 -08:00
window.console_error_redirect(orig_console_error, args);
Add support for headless testing This commit adds support to the `wasm-bindgen-test-runner` binary to perform headless testing via browsers. The previous commit introduced a local server to serve up files and run tests in a browser, and this commit adds support for executing that in an automated fashion. The general idea here is that each browser has a binary that implements the WebDriver specification. These binaries (typically `foodriver` for the browser "Foo") are interfaced with using HTTP and JSON messages. The implementation was simple enough and the crates.io support was lacking enough that a small implementation of the WebDriver protocol was added directly to this crate. Currently Firefox (`geckodriver`), Chrome (`chromedriver`), and Safari (`safaridriver`) are supported for running tests. The test harness will recognize env vars like `GECKODRIVER=foo` to specifically use one or otherwise detects the first driver in `PATH`. Eventually we may wish to automatically download a driver if one isn't found, but that isn't implemented yet. Headless testing is turned on with the `CI=1` env var currently to be amenable with things like Travis and AppVeyor, but this may wish to grow an explicit option to run headless tests in the future.
2018-07-25 03:34:35 -07:00
else
Use splat instead of `arguments` in tests Previously `arguments` was used to pass around an array of arguments, but this wasn't actually a `js_sys::Array` but rather a somewhat esoteric internal object. When switching over `Array` methods to be `structural` this caused issues because the inherent methods on an `arguments` object were different than that of `js_sys::Array`.
2018-11-08 11:46:52 -08:00
orig_console_error.apply(this, args);
Add support for headless testing This commit adds support to the `wasm-bindgen-test-runner` binary to perform headless testing via browsers. The previous commit introduced a local server to serve up files and run tests in a browser, and this commit adds support for executing that in an automated fashion. The general idea here is that each browser has a binary that implements the WebDriver specification. These binaries (typically `foodriver` for the browser "Foo") are interfaced with using HTTP and JSON messages. The implementation was simple enough and the crates.io support was lacking enough that a small implementation of the WebDriver protocol was added directly to this crate. Currently Firefox (`geckodriver`), Chrome (`chromedriver`), and Safari (`safaridriver`) are supported for running tests. The test harness will recognize env vars like `GECKODRIVER=foo` to specifically use one or otherwise detects the first driver in `PATH`. Eventually we may wish to automatically download a driver if one isn't found, but that isn't implemented yet. Headless testing is turned on with the `CI=1` env var currently to be amenable with things like Travis and AppVeyor, but this may wish to grow an explicit option to run headless tests in the future.
2018-07-25 03:34:35 -07:00
};
Support asynchronous tests (#600) * Tweak the implementation of heap closures This commit updates the implementation of the `Closure` type to internally store an `Rc` and be suitable for dropping a `Closure` during the execution of the closure. This is currently needed for promises but may be generally useful as well! * Support asynchronous tests This commit adds support for executing tests asynchronously. This is modeled by tests returning a `Future` instead of simply executing inline, and is signified with `#[wasm_bindgen_test(async)]`. Support for this is added through a new `wasm-bindgen-futures` crate which is a binding between the `futures` crate and JS `Promise` objects. Lots more details can be found in the details of the commit, but one of the end results is that the `web-sys` tests are now entirely contained in the same test suite and don't need `npm install` to be run to execute them! * Review tweaks * Add some bindings for `Function.call` to `js_sys` Name them `call0`, `call1`, `call2`, ... for the number of arguments being passed. * Use oneshots channels with `JsFuture` It did indeed clean up the implementation!
2018-08-01 15:52:24 -05:00
window.__wbg_test_invoke = f => f();
Add support for headless testing This commit adds support to the `wasm-bindgen-test-runner` binary to perform headless testing via browsers. The previous commit introduced a local server to serve up files and run tests in a browser, and this commit adds support for executing that in an automated fashion. The general idea here is that each browser has a binary that implements the WebDriver specification. These binaries (typically `foodriver` for the browser "Foo") are interfaced with using HTTP and JSON messages. The implementation was simple enough and the crates.io support was lacking enough that a small implementation of the WebDriver protocol was added directly to this crate. Currently Firefox (`geckodriver`), Chrome (`chromedriver`), and Safari (`safaridriver`) are supported for running tests. The test harness will recognize env vars like `GECKODRIVER=foo` to specifically use one or otherwise detects the first driver in `PATH`. Eventually we may wish to automatically download a driver if one isn't found, but that isn't implemented yet. Headless testing is turned on with the `CI=1` env var currently to be amenable with things like Travis and AppVeyor, but this may wish to grow an explicit option to run headless tests in the future.
2018-07-25 03:34:35 -07:00
</script>
<script src='run.js' type=module></script>
</body>
</html>
Reference in New Issue Copy Permalink