3.x: review features of the test consumers

[akarnokd]

• Review available assertions.
• Remove redundant assertions.
• Resolve ambiguities about the assertions.
• Rething naming of assertions.

[vanniktech]

The more I'm using it the more I feel like assertValues should be removed. It only asserts half of the things. Using assertValuesOnly, assertResult, or the overload with the error matcher would be more pragmatic.

If the main code gets changed and suddenly the source completes the unit test would not break with assertValues. Often times distinguishing between a completing and not completing Observable / Flowable really does matter.

[sircelsius]

Maybe I'm being naive, but for most of my more advanced test cases I end up getting the onNext events and asserting on them directly. I have never encountered a case where assertValues was useful.

My understanding is that assertCompleted, assertValueCount and the likes are enough for simple test cases, and clients get little value from assertValues for more complex cases.

[akarnokd]

Please don't forget that the test consumer is there to test RxJava itself, not just your code out there.

[JakeWharton]

But if those requirements differ then the APIs should be split.

[sircelsius]

+1, I don't really get why methods used to test RxJava internals should be exposed to clients

[akarnokd]

The Java language doesn't allow hiding methods from non-project usages.

[JakeWharton]

.to(test()) isn't that much longer than .test().

[akarnokd]

Type inference may not work most of the time, requiring a full expression with type arguments for that test.

[JakeWharton]

And thankfully as the library we bear that extra burden so that our consumers don't have to!

[akarnokd]

I've composed a questionare about the test support:

https://docs.google.com/forms/d/1kiuYMVxbDjsPhIjWMG4V4aiHUevhCI9BzOmlRd-OWhs

Let me know what you think and if adequate, I'll tweet it out.

[vanniktech]

Maybe reduce the number of options one can give to each operator or use a better control UX-wise.