- From: Adam Rice <notifications@github.com>
- Date: Fri, 10 Nov 2017 08:15:35 +0000 (UTC)
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/streams/issues/548/343405111@github.com>
Some notes from recently porting some tests to not use non-zero delays: If there is only one delay() in the test, then it's probably only being used to test async behaviour, and can just be replaced by delay(0). If there are negative assertions (assertions that something has **not** happened) in the test then you may need to use flushAsyncEvents(). Even many tests that use delay(_n_) for sequencing can be easily rewritten without non-zero delays. Here's four examples, only one of which results in a non-deterministic ordering: ```javascript // Example (1) delay(10).then(a); delay(20).then(b); // Example (2) delay(10).then(a); someOtherEvent.then(() => delay(20)).then(b); // Example (3) someOtherEvent.then(() => delay(10)).then(a); delay(20).then(b); // Example (4) delay(10).then(a); delay(10).then(b); ``` In examples (1), (2) and (4), `a` happens deterministically before `b`, and so they can be rewritten using chained promises. In example (3) the order may be nondeterministic. In the general case, tests with non-zero delays implicitly test the ordering of events and should be rewritten to _explicitly_ test ordering instead. Usually the recording stream test helpers in `streams/resources/recording-streams.js` are the right tools for this. The tricky part is identifying those implicitly tested ordering expectations. It's easy to rewrite the test so it looks the same and passes, but accidentally reduce the power of the test in identifying incorrect implementations. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/streams/issues/548#issuecomment-343405111
Received on Friday, 10 November 2017 08:15:58 UTC