gmusicapi
gmusicapi copied to clipboard
simon-weber
Robust unit tests
I think that to honor the true point of a unit test, we should be creating dummy replacements for things like the protocol packages so we don't necessarily need authentication to run tests on the abstraction code, and only the protocol stuff, which we should really test directly, so we can differentiate between errors in the abstraction and errors in the protocol itself, which is the whole point of the unit tests. Also so that we can run at least some tests in a pull request, so we aren't blind merging, which is never a good thing.
Also, setting up coveralls should be really simple and seems worthwhile.
I'm willing to handle this if you'd like (I've pretty much given up on trying to figure out #242, and I'm pretty free these days)
There are a few unit tests currently: local_tests. These should be run for pull requests -- I should have thought of that when handing #249.
re: adding mocking, I'm not sure how much value it would provide, at least implemented how I'm picturing it (something like VCR.py). Tests like those would only be able to catch a very specific kind of regression, that satisfies all of:
- wasn't caused by a serverside change
- wasn't introduced along with a purposeful change in request format
- only depends on clientside state
It could catch typos or some unintentional changes in request format, but not much else. I'd be more interested in setting up a public test account (which I think 2-factor auth would allow).
re: coveralls, yeah, that'd be cool.
To your mocking points (EDIT: pun not intended), the mock would maintain an internal state and ensure that the correct operations have been completed. This means that when, say, somebody updates the protocol in a PR, they would update the mock and we would be able to see whether the wrapper stuff still works as expected.
Although I do accept that in a library like this which is essentially dependent on a server backend that isn't maintained by us it might be a little overkill.