Dummy premium accounts for library developers

Dummy premium accounts for library developers




I'm a developer from the rspotify library, a Rust wrapper for the Spotify Web API. I also worked on tekore a bit, which is another wrapper but written in Python.


The issue I'm facing at rspotify is that to run tests that require OAuth automatically (with GitHub Continuous Integration for instance), I need a refresh token for an account with Spotify Premium to access the different endpoints the Spotify Web API exposes. The refresh token doesn't expire as often as an access token, so it's good enough for the tests.


The main tekore developer, Felix Hildén, currently uses his own personal account for this, which does work, but is far from ideal because the tests have to be written so that they don't modify his profile, and has to be secret so that noone else has access to it.


But for rspotify none of the devs (including myself) want to share their refresh token to run these tests for different reasons, specially because it gives access to the full account and we consider that too risky as open source collaborators.


We were wondering if it'd be possible to have Spotify offer "development accounts" for such testing purposes. The accounts themselves wouldn't even need to work to listen to music, only for the Spotify Web API endpoints, so the cost for this proposal would be none.


This is beneficial for Spotify because this way the Web API libraries could write considerably improved tests, and with it, Spotify would have a more stable and robust ecosystem. Not only would that increase the quality of the apps, but also Spotify's usage to some extent.

4 Replies

Does that not make your tests really slow? We've always mocked out anything outside of our code which includes all requests to Spotify's servers.


Hi @marioom! Sorry, we don't currently have test premium accounts for developers. As @kingosticks4 points out, there are some benefits to writing tests that do not make live calls to the API. This allows you to run your tests while offline for example.

Sorry for the late reply!

How does that make the tests slow? Testing every single endpoint is essential for any mature library, it wouldn't even matter in that case. But the devs at Tekore already do this and they haven't reported any issues. Their CI takes no longer than 3 minutes:

The endpoints frequently change the requests/responses and breaks the library. I haven't found a way to stay updated on these changes efficiently, and even then, some of them are undocumented (when you go to the official endpoint page, it hasn't been updated). Running tests for the endpoints seems like the most solid approach to me, and to many other devs.

Hi @spotifyjosh,

As I replied to @kingosticks4, the advantages outweigh the benefits you mentioned. Offline tests miss the point because I'm mainly talking about automatic ones with Continuous Integration (which requires a connection to the machine they run on, and to download packages). This API changes with relative frequency and being able to spot new changes before someone has to open a new issue on GitHub would help a lot. Specially to remove some of the work the devs have to do to maintain these libraries. I know these devs are volunteers after all; if you don't want to spend more time on it, just don't. But in some way they considerably help the Spotify community grow, so they could get some help with their tasks.

Also, I might have misunderstood this forum. It's a feature request, so even though it's not a thing already, it could become so, right? Other devs would also support this. Not sure if I posted this in the appropriate place.

Suggested posts

Env: prod