fix: update tests.py to pass, add to github workflow #576
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As I mentioned on my other PR, I noticed that
tests.py
was failing, looks like the code under test changed out from under it over time. This gets it all passing again. I added it to the github workflow, so that hopefully they can be more useful.For the colour and white light tests, the values changed. I am assuming the new ones are correct, just for a different variant. I left the old ones commented out.
I reworked how the tests use mocks. I change them to use
return_value
instead ofside_effect
, and to grab the "results" (really, what the library wanted to send) from.call_args
. That allowed me to eliminate a separate mock function for each test.The also now mostly deals with Python dicts instead of decoding the binary format. That is mainly because of how
_send_receive
works. (I assume it used to not do that decoding, but I didn't really dig into the history).I also added section comments, the standard-ish "arrange" / "act" / "assert" comments plus "gather results" and "expectations". I can remove those if you don't like them of course. Personally I like to at least have an "act" or "execute" comment in my unit tests, because I find that line, which is the important thing-you're-actually-testing line, often gets lost among all the setup code.