wasm-bindgen/crates/cli/src/bin/wasm-bindgen-test-runner/index-headless.html

<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`;
        }
      };
      console.log = function(...args) {
        if (window.console_log_redirect)
          window.console_log_redirect(orig_console_log, args);
        else
          orig_console_log.apply(this, args);
      };
      console.error = function(...args) {
        if (window.console_error_redirect)
          window.console_error_redirect(orig_console_error, args);
        else
          orig_console_error.apply(this, args);
      };
      window.__wbg_test_invoke = f => f();
    </script>
    <script src='run.js' type=module></script>
  </body>
</html>
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>`