Skip to content

VarArg parameters for the assertReceivedOnNext(T... items) #2881

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

Unisay
Copy link

@Unisay Unisay commented Apr 15, 2015

Syntactic simplification for the assertReceivedOnNext(List<T> items).
Instead of

testSubscriber.assertReceivedOnNext(Arrays.asList(1, 2, 3))

(almost all existing calls use Arrays.asList())
proposed vararg method

testSubscriber.assertReceivedOnNext(1, 2, 3)

looks simplier and nicer.

@akarnokd
Copy link
Member

Hi. First of all, this is an incompatible change since the TestSubscriber is a public API and needs to maintain its method signatures. Second, varargs in Java 6 is problematic and we can't use the SafeVarargs annotation: the moment you try to assert an array of list of values, you get the unchecked warning.

@Unisay
Copy link
Author

Unisay commented Apr 15, 2015

@akarnokd, regarding the change incompatibility: I have only introduced new method with varargs, the method with list remains available, so should not break anything.
As for your second point: I see the problem with Java 6. Is compiler warning a blocker?

@akarnokd
Copy link
Member

You're right, I've misread the diff page. The warning isn't a real blocker but we'd like to avoid much of it as possible.

As a matter of fact, I happen to have a PR in which the TestSubscriber is also expanded with lots of useful methods.

Regardless, I wouldn't have changed tests to use the new method since we usually don't look at test unless there is a problem with them. In that case or with new tests, the developers are free to use the more convenient methods.

@benjchristensen
Copy link
Member

@akarnokd I'm trying to figure out if this will cause any of the issues that made us move away from varargs in the past. You seem to have concluded that it won't?

Also I need to make sure the overload won't conflict with dynamic languages like Groovy and Clojure.

@Unisay Can you add the method without changing all the unit tests so this doesn't affect 30 files that don't need to be changed? Please rebase the change so it is a single commit just touching TestSubscriber.

@akarnokd
Copy link
Member

I'm not sure about dynamic languages but I'd prefer a shorter assertValues(Object... values).

@benjchristensen
Copy link
Member

Handling in #2948 without changing the other 30 files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants