3 Commits

Author SHA1 Message Date
Alex Crichton
b013ec6288 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
Alex Crichton
eee71de0ce
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
Alex Crichton
7b4f0072c8 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-30 11:07:07 -07:00