While @jaebradley is the only contributor to this project, it's fine to run tests against the actual WakaTime API using his account and credentials. However, in the future, it might be beneficial to stub the endpoints to make tests more predictable. E.g. WakaTimeClient Integration Test › getUser › gets user details expects a specific user object and therefore will fail when run against a different WakaTime account. Also, it feels somewhat odd to run tests against the production web service.
I'm not too involved in the JavaScript ecosystem, so I don't have any concrete proposals on how to best realize this. In the Java world, tools like WireMock exist. Probably there are (maybe more lightweight) alternative for Node projects as well.
While @jaebradley is the only contributor to this project, it's fine to run tests against the actual WakaTime API using his account and credentials. However, in the future, it might be beneficial to stub the endpoints to make tests more predictable. E.g.
WakaTimeClient Integration Test › getUser › gets user detailsexpects a specific user object and therefore will fail when run against a different WakaTime account. Also, it feels somewhat odd to run tests against the production web service.I'm not too involved in the JavaScript ecosystem, so I don't have any concrete proposals on how to best realize this. In the Java world, tools like WireMock exist. Probably there are (maybe more lightweight) alternative for Node projects as well.