Global Contract Tests via Unit Tests

[benjchristensen]

I'm wondering if there is a way for us to create an AbstractTest class that we could implement for each operator that would have a series of specification tests, similar to a TCK that assert core behavior as opposed to the operator functionality.

For example:

• subscribe and unsubscribe
• request(Long.MAX_VALUE)
• request(0)
• request(n < 0)
• request(n > 0)
• scalar
• vector
• infinite
• async and sync variants of each
• concurrency (where applicable, such as unsubscribe and request)

It would require the implementation classes providing an Observable impl with each operator configured correctly for the various cases, but then the abstract portions could do the pounding and prove the basics for all operators.

This would be a great addition for someone looking to contribute. If someone has the time to tackle this I'd be happy to review the approach, specifications and tests while getting started. We should prove it on a few operators first before making the effort for all of them. For example map, take, merge, groupBy.

[akarnokd]

And perhaps test for the special case of unsubscribe after onError or onCompleted not unsubscribing the downstream since I could do some async work after onError or onCompleted before I tell my downstream how to complete.

[abersnaze]

I've been thinking about a general operator testing as well. I think we'll need an alternate iterable implementation of the each operator to use as the expected behavior to assert against.

actual = Observable.from(input).lift(observableOp).toList().toBlocking().single()
expected = iterableOp.call(input)

[davidmoten]

I've had a play with this one. It's not fully unit tested but appears to be working so far and I'm already finding this very useful for testing custom Operators. This may not be what people are envisaging but might nethertheless be useful for pushing discussion.

The page below demos a sync test for count and an async test for merge.

https://github.com/davidmoten/rxjava-extras

[benjchristensen]

Closing in favor of #2783 for 2.0.