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.

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.

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

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

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

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

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

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

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

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.

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

I've tried a matrix-choice control but Google Docs doesn't allow me to change the width of the form thus it introduced a horizontal scrollbar you'd have to scroll left-right all the time. The choices should also help with the original tasks, for example, which operators should be renamed.

Good questionare 👍

I'm a bit afraid though, that because many don't understand the difference between some of the assertion methods in the first place, questionare results might be misleading.

Hopefully people will look into javadocs, maybe questionare should have links to each method/type javadoc in case people don't have IDE/sources at hand.

There is the implicit assumption that people know which methods they have used and if the others don't ring a bell, they will simply chose the remove/not-using/no opinion.

Updated the form with links to each method's JavaDoc.

My issue is that the APIs don't consume events as you assert so you constantly have to supply all events or awkwardly remove events separate from assertion. I always end up writing my own test observer as a result.

Reactor uses a different approach: StepVerifier. Note however that there were complications: expressing testing events over time, synchronizing through a test scheduler, etc.

I wonder if content-assist filters in one's IDE would help with the method "bloat" experienced with RxJava?

I’ll express the feedback I’ve collected browsing through the project I’m working on (and I’m too lazy to describe all assertions available). We have something like 15K+ tests, a lot of them include RxJava checks.

We have a specific rule to generally avoid termination events, especially errors — basically we treat them as failures, i. e. something went horribly wrong and someone produced onError. That said, we don’t use much.

• Most of the time we create TestObserver explicitly, subscribe and work with it directly.
• The test() method is rarely used since we have complex multi-step checks (hey BDD) and it does not scale for such situations.
• The most common assertion we use is assertValuesOnly and there is an ongoing push to replace every assertValue with it since it provides more checks under the hood. And actually something like assertValueOnly would be a better fit for us.
• Next go assertResult and assertEmpty — again, both of them are better checks than assertValue and assertNoValues.

Regarding what can be done better — we have a custom cleanup extension that clears current values in TestObserver. It allows us to write more lean tests:

context("event") {
    it("emits value A") { valueObserver.assertValuesOnly("A") }

    context("different event") {
        beforeEachTest { valueObserver.clear() }
        
        it("emits value B") { valueObserver.assertValuesOnly("B") }
        // Without clear() above we need to check both values, i. e. assertValuesOnly("A", "B")
    }
}

It is similar to Mockito.clearInvocations() and can be useful, but we are fine with using our own thing.

I wouldn’t mind moving TestScheduler, TestObserver and friends into a separate artifact. Pretty sure we can live without the Observable.test() method.

Otherwise we are satisfied with the current set of asserts. The naming is a bit confusing and it leads to discoverability issues — I had to explain the difference between assertValue and assertResult a couple of times. Maybe something like assertOnNext, assertOnNextOnly can be a better fit. Also, think about removing complex checks like assertValuesOnly altogether since it forces you to create smart naming which combines multiple actions. assertResult is understandable, but I think there is no result term in reactive world.

assertValues is extremely helpful and I would prefer to have it in future releases as well.

The results of the questionare (34 responses). Bold indicates the dominant factor for the proposed action to take.

From the additional comments

• using mainly values()
• rename confusing methods (empty)
• provide additional specific test consumer types for base reactive types³
• focus on testing, provide docs about how to test
• likes the test() API's existence
• likes the test functionality but RxJava should ship the test support separately via helpers
• better AssertJ support via callback having all events provided as parameters

Methods used for testing mainly by RxJava will be moved to the test-only TestHelper class. Some removed features may require an RxJava internal subclass instead to access protected internal state.

Remarks

^{1, 2} these are redundant, may remove dispose from TestSubscriber and remove cancel from TestObserver.
³ would match the event terminology better (assertSuccess) but introduces redundancy.

Closing via #6526.