Does this have merit?

[vweevers]

I think an "abstract test suite" for streams (akin to abstract-leveldown) would be great to have because:

1. For implementors, it's hard to keep up with changes in Node
2. Implementors could skip writing boilerplate tests (with assumptions about how streams should work)
3. Serves as a signal to consumers (similar to how one can identify streams2 npm packages by their name). A module can depend on readable-stream but this is not enough of a guarantee that it behaves the same. For example, many modules have implemented their own non-underscored destroy() with inconsistent semantics as well as their own destroyed state tracking. Merely updating the version of readable-stream won't fix that and an upgrade guide does not exist.
4. Could also help to homogenize node core modules like fs, or at least to identify differences
5. Can canary-test integration with popular utilities like pump/pipeline and end-of-stream/finished.

@mcollina @mafintosh I would love to hear your thoughts if you have time.

[mcollina]

I think it does. Definitely something it's worth having, and including it in the docs as well.

My only question is.. how much of this could be generic, and not tied to a stream? We cannot really verify that the data is correct, so we should focus on signal ordering, etc.

The inconsistency also exists in Core (OutgoingMessage for example), so it might be very good to have this test suite available.