jgraham
commented
2 years ago So, to be clear I'm not wedded to the proposed setup. But I'm also skeptical of making the API surface a multi-producer, multi-consumer queue in which we expose a way for anyone with the token to both read and write. The problem with that design is that I fear it will lead to hard-to-debug flakiness where for timing reasons one context reads something that was supposed to be read by a different context, and the whole implicit protocol breaks down. Constraining who can read from a queue, even if multiple people can write to it, seems to encourage more robust designs.
That said, I agree that the proposal doesn't address the use case of multiple tests running concurrently, and all wanting to communicate back to the test context without needing complex dispatch. One way to extend the proposal to support that might be to allow something like [receiver, sender] = test_driver.channel(); remote_context.send(sender); await reciever.recv() i.e. you'd get seperate objects implementing the send() and poll()/recv() parts of the protocol, and it would be possible to send() the sender (but not the receiver) to a remote context so you'd get a unique channel per test to communicate back results. For example, in the test window:
let uuid = "{{uuid}}"';
window.open(`child.html?uuid=${uuid}`, "_blank", "noopener");
let remote = new test_driver.RemoteContext(uuid); // This only implements send()
let [receiver, sender] = new test_driver.Channel()
await remote.send(sender);
// Listen for a message from the remote end
await reciever.recv()and in child.html:
let test_channel = test_driver.recv();
try {
let result = await do_test();
test_channel.send({status: OK, result: result});
} catch(e) {
test_channel.send({status: "ERROR", message: e.toString()});
}So test_driver would automatically implement the receiver API for the current context (and we could also make that available in workers / remote contexts), and given a uuid, it would be possible to construct a sender, but not a receiver.
One thing that might be useful here is to look at use cases. For example:
- Test wants to get some data from a browsing context in a different browsing context group in order to make asserts about it
- Test wants to get some data from a worker running in a different origin to make some asserts about it
- Multiple subtests on the same page want to create browsing contexts/workers and get results back from those workers
- Test wants to observe events happening in a remote context/worker (e.g. check that a load event happens)
And maybe some higher level ones:
- Test wants to send over some script to run in a different context/worker and get the result of the execution back
- Want to run
assert()functions outside the test window (in a different browsing context group) and communicate back the asserts run and their results (c.f. fetch_tests_from_window etc.).
Does that sound like a reasonable start? What am I missing?
ArthurSonzogni
Add send()/poll()/recv() functions that can be used to pass arbitary messages to other testdriver contexts, to help with test scenarios requiring multiple origins