2.0 Design: Test Suite

[benjchristensen]

As we define the RxJava 2.0 spec and design guidelines let's put in place contractual tests that are uniform and can be applied to every operator right from the beginning.

This needs to account for the various permutations of an Observable such as:

• scalar synchronous
• finite synchronous
• infinite synchronous
• empty synchronous
• error synchronous
• scalar asynchronous
• finite asynchronous
• infinite asynchronous
• empty asynchronous
• error asynchronous
• never
• hot (no backpressure support)
• cold (backpressure support)
• slow consumer
• fast consumer
• data less than default buffer sizes
• data more than default buffer sizes

Preferably we would have a base or abstract implementation of these that can be reused to drive concrete implementations for each operator.

[akarnokd]

The RS specification prohibits throwing from onNext, onError and onCompleted anything but NullPointerException, however, plenty of our tests do throw various exceptions. The question is where do we draw the line for the safety-net: i.e., only around user supplied functions (this includes create/lift as they are have user supplied functions) or everywhere the 1.0 tests expected it?

[benjchristensen]

The RS specification prohibits throwing

So does RxJava and the Rx Design Guidelines originated from Rx.Net.

Our unit tests throw to test how we behave out-of-contract. A spec and interface define how it "should" work. A concrete implementation needs to address how it "will" work which includes out-of-contract scenarios where exceptions are thrown when they shouldn't be. RxJava tries to do "the right thing" even when the contract is being broken.

[akarnokd]

I've written several thousand tests for various operators and each differ a bit in their consumption and emission patterns that I wasn't able to write a "test suite for any and all" but only individual tests. The closest thing is the RS TCK we use for testing our operators but that's it.