3.x: review features of the test consumers #6153
Comments
|
The more I'm using it the more I feel like If the main code gets changed and suddenly the source completes the unit test would not break with |
|
Maybe I'm being naive, but for most of my more advanced test cases I end up getting the My understanding is that |
|
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. |
|
|
|
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
Regarding what can be done better — we have a custom cleanup extension that clears current values in 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 I wouldn’t mind moving 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 |
|
|
|
The results of the questionare (34 responses). Bold indicates the dominant factor for the proposed action to take.
From the additional comments
Methods used for testing mainly by RxJava will be moved to the test-only Remarks 1, 2 these are redundant, may remove |
|
Closing via #6526. |
The text was updated successfully, but these errors were encountered: