starred/rspotify

Fork 0

mirror of https://github.com/ramsayleung/rspotify.git synced 2026-04-25 23:45:52 +03:00

[GH-ISSUE #154] Testing OAuth endpoints #57

New issue

Closed

opened 2026-02-27 20:22:51 +03:00 by kerem · 6 comments

kerem commented

2026-02-27 20:22:51 +03:00

Owner

Originally created by @ramsayleung on GitHub (Nov 16, 2020).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/154

It's a little bit awkward that most endpoints implemented in rspotify which require oauth token to go haven't have some related unit tests.

Since most tests will depend on Spotify Web API, and have to obtain the oauth token before sending request to Spotify server. The problem there is no a proper way to get oauth token, it has to open a browser and sign in with specific scopes, and now the process can't be automated.

#[maybe_async]
#[maybe_async_test]
#[ignore] // we have to ignore those tests for the reason discussed above.
async fn test_current_user_playing_track() {
    oauth_client()
        .await
        .current_user_playing_track()
        .await
        .unwrap();
}

As everything goes without saying, tests are essential, and we should figure out a proper way to add test for endpoints.

Originally created by @ramsayleung on GitHub (Nov 16, 2020). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/154 It's a little bit awkward that most endpoints implemented in `rspotify` which require `oauth` token to go haven't have some related unit tests. Since most tests will depend on Spotify Web API, and have to obtain the `oauth` token before sending request to Spotify server. The problem there is no a proper way to get `oauth` token, it has to open a browser and sign in with specific scopes, and now the process can't be automated. ```rust #[maybe_async] #[maybe_async_test] #[ignore] // we have to ignore those tests for the reason discussed above. async fn test_current_user_playing_track() { oauth_client() .await .current_user_playing_track() .await .unwrap(); } ``` As everything goes without saying, tests are essential, and we should figure out a proper way to add test for endpoints.

kerem

2026-02-27 20:22:51 +03:00

closed this issue
added the
enhancement

Stale

help wanted

discussion
labels

kerem commented

2026-02-27 20:22:52 +03:00

Author

Owner

@marioortizmanero commented on GitHub (Nov 16, 2020):

The main blocking issue is that we don't have a premium account to run these tests on. I tried to request tokens for library maintainers, here's the post in their forum for developers: https://community.spotify.com/t5/Spotify-for-Developers/Dummy-premium-accounts-for-library-developers/m-p/5046929. For now you can press Like and leave a comment with your thoughts, but it seems to be somewhat stale. We should notify other maintainers for spotify libraries to support this issue and get some traction.

Before we run any tests with oauth though we have to make sure they don't modify the user's data (for example first testing following users and then unfollowing them).

@marioortizmanero commented on GitHub (Nov 16, 2020): The main blocking issue is that we don't have a premium account to run these tests on. I tried to request tokens for library maintainers, here's the post in their forum for developers: https://community.spotify.com/t5/Spotify-for-Developers/Dummy-premium-accounts-for-library-developers/m-p/5046929. For now you can press Like and leave a comment with your thoughts, but it seems to be somewhat stale. We should notify other maintainers for spotify libraries to support this issue and get some traction. Before we run any tests with oauth though we have to make sure they don't modify the user's data (for example first testing following users and then unfollowing them).

kerem commented

2026-02-27 20:22:52 +03:00

Author

Owner

@marioortizmanero commented on GitHub (Feb 25, 2021):

Additionally, it could be a good idea to have a GitHub action with a cronjob that periodically (say, once a day) checks that the endpoints work. This would let us know about changes in the Spotify API very early and give us more time to apply them. Here's how tekore does it.

@marioortizmanero commented on GitHub (Feb 25, 2021): Additionally, it could be a good idea to have a GitHub action with a cronjob that periodically (say, once a day) checks that the endpoints work. This would let us know about changes in the Spotify API very early and give us more time to apply them. Here's how tekore does it.

kerem commented

2026-02-27 20:22:52 +03:00

Author

Owner

@typecasto commented on GitHub (Jul 6, 2021):

Could you not use a self-hosted runner and your own personal spotify account? While it isn't ideal, the spotify devs don't exactly seem receptive to the issue.

This would keep the credentials private, since nobody else has access to the .env file or your token. As far as not modifying the account, are there any API calls that don't have an inverse? You could test the playlist creation endpoint, which creates a playlist, then test the get user playlists endpoint, which would find that playlist (and ignore all the others), then test the delete user playlists endpoint, which would delete that playlist. Overall, this has no net impact on your playlists, since it creates and then deletes one immediately after. I'm unaware of any endpoints that don't have some inverse operation like that (or have any impact at all).

Also, what are the restrictions on a free account? No API access at all?

@typecasto commented on GitHub (Jul 6, 2021): Could you not use a [self-hosted runner](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) and your own personal spotify account? While it isn't ideal, the spotify devs don't exactly seem receptive to the issue. This would keep the credentials private, since nobody else has access to the .env file or your token. As far as not modifying the account, are there any API calls that don't have an inverse? You could test the playlist creation endpoint, which creates a playlist, then test the get user playlists endpoint, which would find that playlist (and ignore all the others), then test the delete user playlists endpoint, which would delete that playlist. Overall, this has no net impact on your playlists, since it creates and then deletes one immediately after. I'm unaware of any endpoints that don't have some inverse operation like that (or have any impact at all). Also, what are the restrictions on a free account? No API access at all?

kerem commented

2026-02-27 20:22:52 +03:00

Author

Owner

@marioortizmanero commented on GitHub (Jul 6, 2021):

Yes, we can use our personal accounts keeping the credentials private, but:

You open up the possibility of leaking the account. Not like it's easy to do so, but it's an unnecessary risk I don't really want to take.
Most endpoints do have an inverse, but running tests on the account is still sketchy. What if the "delete playlist" is the one test that fails? I'd have garbage in my account. And similars. Yes, you can reverse most of them, but you can still end up with a modified account.

I was hoping Spotify could help us by providing a premium account for the tests, but seeing that it's not happening I will consider using mine. Before releasing the new version we have to modify the oauth tests so that they don't modify the user's account anyway, so I'll decide after that's done and I can try it locally.

And yes, you can't access OAuth endpoints with a free account.

@marioortizmanero commented on GitHub (Jul 6, 2021): Yes, we can use our personal accounts keeping the credentials private, but: 1. You open up the possibility of leaking the account. Not like it's easy to do so, but it's an unnecessary risk I don't really want to take. 2. Most endpoints do have an inverse, but running tests on the account is still sketchy. What if the "delete playlist" is the one test that fails? I'd have garbage in my account. And similars. Yes, you can reverse most of them, but you can still end up with a modified account. I was hoping Spotify could help us by providing a premium account for the tests, but seeing that it's not happening I will consider using mine. Before releasing the new version we have to modify the oauth tests so that they don't modify the user's account anyway, so I'll decide after that's done and I can try it locally. And yes, you can't access OAuth endpoints with a free account.

kerem commented

2026-02-27 20:22:52 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Jul 4, 2023):

Message to comment on stale issues. If none provided, will not mark issues stale

@github-actions[bot] commented on GitHub (Jul 4, 2023): Message to comment on stale issues. If none provided, will not mark issues stale

kerem commented

2026-02-27 20:22:52 +03:00

Author

Owner

@tomkimsour commented on GitHub (Aug 30, 2023):

Is there a command to run these tests on local ? I'm trying to test the playlist endpoint but I can't figure the command to run to test oauth and bypass the ignore without removing the attribute

@tomkimsour commented on GitHub (Aug 30, 2023): Is there a command to run these tests on local ? I'm trying to test the playlist endpoint but I can't figure the command to run to test oauth and bypass the ignore without removing the attribute

kerem referenced this issue

2026-02-27 20:23:48 +03:00

[PR #57] [MERGED] add missing device types #213