PlexTraktSync
PlexTraktSync copied to clipboard
Taxel
Add testing to the project
With logic being isolated in newer PR's, it should make it possible to do unit and e2e testing.
Here's some related projects, which start PMS to use for testing:
- https://github.com/pkkid/python-plexapi
- https://github.com/andrey-yantsen/plex-api.rs
Tests would be appreciated for sure. Weeks ago,I started writing some for trakt_list_util (I'm newbie about unittests so personal use only).
after reading this blog:
- https://realpython.com/python-testing/
I decided to try pytest due it's simplicity writing tests and bundled with python.
Some tests are added, just to have the development aid of testing certain part of the code:
- https://github.com/Taxel/PlexTraktSync/tree/0.7.22/tests
There's no structure there.
Ideally should have a common library that all tests can use. The object mocking should likely use something existing.
Anyway, to run the tests:
pytest path/to/test/file.py
# or
python3 -m pytest path/to/test/file.py
The tests I wrote for trakt_list_util are using mockdata from pytrakt project. Do you think it's a good idea ?
not sure what the mockdata is, could not find what loads those json from quick look. but pytrakt also seem to use pytest as rest runner.
It is fake data so we can test each and every function of our code without connecting to a real trakt/plex account.
@twolaw I mean I don't know and on quick look did not understand how the files in mockdata used, so can't even say is it something they cooked on their own, or some library supports those files.
It is loaded with conftest.py as a Mock object to fake all trakt answers. Very smart. We could do the same with Plex.
Yes, found it, already using a similar approach:
- https://github.com/Taxel/PlexTraktSync/pull/259
Yes it's good. But PyTrakt project is Mocking the trakt.core instance which is much better because very close to reality. I wonder if a copy/paste of all their test data is allowed.
ref Testing Click Applications
https://click.palletsprojects.com/en/8.0.x/testing/
@chrillep thanks, but I don't think we should test e2e here, but rather unittest algorithms.