-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Fix stream lookup with 'undefined' stream ID #1552
Fix stream lookup with 'undefined' stream ID #1552
Conversation
Lines 1-67 in
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1552 +/- ##
==========================================
+ Coverage 71.60% 71.84% +0.24%
==========================================
Files 364 364
Lines 6713 6742 +29
Branches 479 484 +5
==========================================
+ Hits 4807 4844 +37
+ Misses 1512 1501 -11
- Partials 394 397 +3 ☔ View full report in Codecov by Sentry. |
I'm not a fan of unit tests. Have you tried testing it by adding the track to the queue, instead of calling actions directly? It should be possible to set it up the same way. |
Sorry, I don't understand how you want me to test. The current test can be simplified a bit by excluding the error, but my first intention was to first prove the issue. The test covers a single, very specific execution path since the function is quite big (which is also the reason why the test is as convoluted as it is). As you can see in 9971065, the fix is quite straight-forward. I don't want to test anything more that the code I changed. I'm open for suggestions. Maybe point me to an existing test which I can use as an example and adapt for this specific case? |
I mean that in Nuclear, I avoid unit tests, unless it's impossible. The default way to test any functionality is by writing integration tests at the level of views or high level containers, which you can see e.g. by inspecting the PlayQueueContainer tests. Do you think this can be moved there? |
I had a look at I attempted to set up a test along with the existing tests of I'm at a loss and don't know how to proceed. |
That container interacts with that function via the const component = render(<TestStoreProvider
store={store}
>
<PlayQueueContainer />
<PlayerBarContainer />
</TestStoreProvider>); If you can't figure it out, you can push whatever you manage to do to your branch, and I'll see if I can help you finish it (just mark your PR as accepting commits from me). We've collaborated like that many times in the past in Nuclear and it's pretty great, we both learn a lot this way. |
We can inspect the queue state without needing |
I pushed my local state. Please let me know if you see what's wrong with the test |
Thanks! I'll try to take a look at this today or tomorrow. |
Ok, I was able to reproduce the infinite loop if I use |
I found out that there's an item placed at index -1 in the queue array, and that's why there's an infinite loop. |
Ok, I fixed it. You were missing an uuid for that test track. After adding it, the test works. |
Thank you! It wasn't obvious to me that the ID was required for tracks in the queue. As to how we proceed with the PR: should I now remove the unit test or rather leave them in place? Let me know what you decide, and also if you see anything else which needs to be done. |
I went ahead and merged it, no harm in having more thorough test coverage. Thanks for contributing this. This was happening because the action+reducer combo updates the tracks by uuid. No uuid, no update. Normally I just reuse the same state from |
I'm afraid that we were too much in a hurry with merging. waitFor(() => expect(state.queue.queueItems.length).toBe(0)); I'm afraid that the test doesn't actually test anything. Please correct me if i'm wrong. |
Oops, this is why you do red-green-refactor. I'm not releasing yet though, so you can just keep pushing to this branch, and I can merge the rest at some later point. If I add |
Though when I'm debugging this, all the actions are dispatched correctly and in order, the track should get removed from the queue. |
Ok, this was pretty easy, the store needs to be reloaded after each check. |
When debugging we usually introduce delays through the debugger and breakpoints and such affect the duration of async operations. It's just a thought. At least we have the unit test, which tells us that the removal logic is working. I'm curious as to how the test can be fixed as I have no idea on how to proceed (I'm completely new to TS, React and this whole ecosystem). |
Makes sense, when you think of it. : ) |
I pushed it directly to master, so if you're interested what it looks like, you can see it there. |
The current queue logic attempts to look-up an (undefined) track ID even if no tracks are available.
Such a look-up doesn't make any sense and the queue behavior should be actually specified for such a case.
I'm willing to fix, refactor the queue functionality and add test coverage if someone is able to provide guidance as to what the correct queue behavior would be.
For now, I just added a first test proving the problematic execution path leading to
streamProvider.getStreamForId(undefined)
.