The way to test

[ramsayleung]

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.

[marioortizmanero]

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]

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.

[typecasto]

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?

[marioortizmanero]

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.

[github-actions[bot]]

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

[tomkimsour]

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