Skip to content
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

2.x: Clarify TestObserver.assertValueSet in docs and via tests #6152

Merged
merged 2 commits into from
Aug 10, 2018

Conversation

akarnokd
Copy link
Member

Clarify that {TestObserver|TestSubscriber}.assertValueSet checks for all received items to be in the provided set, but that set can contain additional elements that could have been received. Unit tests have been added to demonstrate the expected behavior.

Resolves: #6151.

* asynchronous streams.
* <p>
* To ensure that only the expected items have been received, no more and no less, in any order,
* apply {@link #assertValueCount(int)} with {@code expected.size()}.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess ideally method name would indicate that by using a word like contains, maybe add it to 3.x list of changes?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assertValuesIn(Collection<? extends T> expected)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Posted #6153.

Copy link
Contributor

@Stephan202 Stephan202 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One grammar nit and one question :)

Thanks for the rapid response!

* Assert that the TestObserver/TestSubscriber received only the specified values in any order.
* <p>This helps asserting when the order of the values is not guaranteed, i.e., when merging
* Assert that the TestObserver/TestSubscriber received only items that are in the specified
* collection as well irrespective of the order they were received.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

collection as well irrespective of the order they were received.

->

collection as well, irrespective of the order in which they were received.

* asynchronous streams.
* <p>
* To ensure that only the expected items have been received, no more and no less, in any order,
* apply {@link #assertValueCount(int)} with {@code expected.size()}.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As-is this method "ignores" duplicates, while assertValueCount doesn't. If a user wishes to assert that all values were received while allowing for duplicates, they could to .distinct().test(). Is this the preferred approach, and if so, is it worth documenting that too? (Maybe have an example of that in the test below?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The aim is to provide some typical set of assertions with TestObserver. You can always modulate the input flow or simply enumerate contents of the TestObserver manually. I usually try to minimize the cases where additional operators are mentioned in the javadocs because it triggers "what about when using X" type of comments.

@akarnokd akarnokd added this to the 2.2 backlog milestone Aug 10, 2018
@codecov
Copy link

codecov bot commented Aug 10, 2018

Codecov Report

Merging #6152 into 2.x will decrease coverage by 0.06%.
The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff             @@
##                2.x   #6152      +/-   ##
===========================================
- Coverage     98.26%   98.2%   -0.07%     
+ Complexity     6199    6197       -2     
===========================================
  Files           667     667              
  Lines         44857   44857              
  Branches       6213    6213              
===========================================
- Hits          44078   44051      -27     
- Misses          246     263      +17     
- Partials        533     543      +10
Impacted Files Coverage Δ Complexity Δ
.../java/io/reactivex/observers/BaseTestConsumer.java 100% <ø> (ø) 116 <0> (ø) ⬇️
.../operators/flowable/FlowableBlockingSubscribe.java 93.02% <0%> (-4.66%) 10% <0%> (-1%)
...ernal/operators/flowable/FlowableFlatMapMaybe.java 88.88% <0%> (-4.35%) 2% <0%> (ø)
...nternal/operators/parallel/ParallelReduceFull.java 91.08% <0%> (-3.97%) 2% <0%> (ø)
...ternal/operators/observable/ObservablePublish.java 96.46% <0%> (-3.54%) 11% <0%> (ø)
.../io/reactivex/disposables/CompositeDisposable.java 98.14% <0%> (-1.86%) 39% <0%> (-1%)
...internal/operators/flowable/FlowableSwitchMap.java 95.28% <0%> (-1.42%) 3% <0%> (ø)
...a/io/reactivex/internal/util/QueueDrainHelper.java 98.61% <0%> (-1.39%) 57% <0%> (-1%)
...l/operators/observable/ObservableFlatMapMaybe.java 88.23% <0%> (-1.31%) 2% <0%> (ø)
...ernal/operators/flowable/FlowableFromIterable.java 95.18% <0%> (-1.07%) 5% <0%> (ø)
... and 18 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 0e7b8ea...2dd535b. Read the comment docs.

@akarnokd akarnokd merged commit a16f63f into ReactiveX:2.x Aug 10, 2018
@akarnokd akarnokd deleted the AssertValueSetClarification branch August 10, 2018 08:15
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.

4 participants