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.
This commit updates the test harness for in-browser testing. It now no longer
unconditionally uses `fs.writeSync`, for example. Instead a `Formatter` trait is
introduced for both Node/browser environments and at runtime we detect which is
the appropriate one to use.
This commit starts to add support for in-browser testing with
`wasm-bindgen-test-runner`. The current idea here is that somehow it'll be
configured and it'll spawn a little HTTP server serving up files from the
filesystem. This has been tested in various ways but isn't hooked up just yet,
wanted to make sure this was somewhat standalone! Future support for actually
running these tests will be coming in later commits.
This commit moves the `webidl/tests` folder to a new `crates/webidl-tests` crate
(to have a test-only build script) and ports them to the `#[wasm_bindgen_test]`
attribute, which should hopefully make testing much speedier for execution!
* Fix importing the same identifier from two modules
This needed a fix in two locations:
* First the generated descriptor function needed its hash to include the module
that the import came from in order to generate unique descriptor functions.
* Second the generation of the JS shim needed to handle duplicate identifiers in
a more uniform fashion, ensuring that imported names didn't clash.
* Fix importing the same name in two modules
Previously two descriptor functions with duplicate symbols were emitted, and now
only one function is emitted by using a global table to keep track of state
across macro invocations.
* Add renaming of conflicting constructors and operations
* Rename conflicting to overloaded
* Fix newlines
* Use or_insert_with, add a comment to TypeToString
* Use more Rust-like names
* Use opt instead of nullable
* Use argument names instead of argument types if possible
* Drop new for overloaded constructots
* Remove extra newline
* Move WebIDL files from unavailable_overloaded_fn
* Move RTCDataChannel, RTCPeerConnection and Selection to unavailable_option_primitive
* Create bindings for RegExp
* Address review comments
- Split the constructor into two: `new` and `new_regexp`. This way we
can write RegExp::new("foo", "g") rather than
RegExp::new(&JsValue::from("foo"), "g").
- The js_name for the setter for lastIndex should be `lastIndex` and
not `set_lastIndex`. But fixing this causes a panic. Remove the
method for now.
* Try to enable all webidls
* Separate out unavailable webidl files by reason.
* Create record of fully tested WebIDL files
* Update notes to reflect new situation with web-idl
* Make a blank ident fail, disable the necessary widls.
It turns out that all the blank idents came from blank enum variants,
which is allowed in webidl apparently.
* Adding in initial support for all HTML*Element interfaces.
* Fix camelcasing of short HTML interface names
* Disabling span test as breaks on taskcluster
The JS iterator protocol uses duck typing and we don't need separate
ArrayIterator and SetIterator etc types, we can have a single iterator type for
the whole protocol.
