2.x: fix assertValueSequence reversed error message

[akarnokd]

The error message/variable names in TestBaseConsumer.assertValueSequence was reversed: if more items were expected, it said "Fewer" and vice versa.

[codecov]

Codecov Report

Merging #5594 into 2.x will decrease coverage by 0.01%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##                2.x    #5594      +/-   ##
============================================
- Coverage     96.23%   96.22%   -0.02%     
- Complexity     5826     5827       +1     
============================================
  Files           632      632              
  Lines         41467    41467              
  Branches       5745     5745              
============================================
- Hits          39906    39900       -6     
- Misses          613      620       +7     
+ Partials        948      947       -1

Impacted Files	Coverage Δ	Complexity Δ
.../java/io/reactivex/observers/BaseTestConsumer.java	99.65% <100%> (ø)	113 <0> (ø)	⬇️
...ernal/operators/flowable/FlowableFlatMapMaybe.java	91.3% <0%> (-5.32%)	2% <0%> (ø)
.../io/reactivex/internal/functions/ObjectHelper.java	94.73% <0%> (-5.27%)	20% <0%> (-1%)
...ava/io/reactivex/processors/BehaviorProcessor.java	88.49% <0%> (-4.87%)	62% <0%> (ø)
.../internal/operators/flowable/FlowableInterval.java	94.44% <0%> (-2.78%)	3% <0%> (ø)
...tivex/internal/schedulers/TrampolineScheduler.java	92.3% <0%> (-2.57%)	6% <0%> (ø)
...ex/internal/subscribers/InnerQueuedSubscriber.java	94.11% <0%> (-1.97%)	17% <0%> (-1%)
.../io/reactivex/disposables/CompositeDisposable.java	97.24% <0%> (-1.84%)	39% <0%> (-1%)
...nal/operators/flowable/FlowableConcatMapEager.java	97.1% <0%> (-1.16%)	2% <0%> (ø)
...ivex/internal/operators/maybe/MaybeMergeArray.java	96.62% <0%> (-1.13%)	6% <0%> (ø)
... and 15 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9b037c7...33be81d. Read the comment docs.

[vanniktech]

let's remove this then?

[akarnokd]

I say let's keep it to indicate catching te AssertionError is not an accident.

[artem-zinnatullin]

Usually that's done by naming exception as expected:

try {
  // …
  fail();
} catch (AssertionError expected) {
  // Assert exception message, etc.
}

[akarnokd]

Fine.

[artem-zinnatullin]

LGTM, but one more test pls

[artem-zinnatullin]

Usually that's done by naming exception as expected:

try {
  // …
  fail();
} catch (AssertionError expected) {
  // Assert exception message, etc.
}

[artem-zinnatullin]

This change also needs a test

[akarnokd]

There is no behavior change here, just a swapped variable name. I'll restore the original u - expected, v - actual naming

[artem-zinnatullin]

Ah. Well at least we have a valid reason to start working on RxJava 3 — kill these one-letter variable names