Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a Python package & add a test suite #493

Open
wants to merge 8 commits into
base: development
Choose a base branch
from

Conversation

paravoid
Copy link

@paravoid paravoid commented Jan 9, 2020

This does three principal things:

  • Moves all Python scripts into a new Python package (dubbed smarthack, based on filenames that I saw in the codebase).
  • Adds a test suite (using pytest) to the codebase with a battery of tests for most modules, checking against Python 3.6 & Python 3.7.
  • Adds a tox.ini for running the test suite, as well as tests for the test suite itself using tox.

The test suite is written using (old and) modern Python standards - it's PEP8-formatted using black, and has docstrings as well as type hints everywhere. It passes through flake8, flake8-import-order, flake8-docstring, pylint, mypy and black. It also runs code coverage numbers using coverage.py.

The test suite currently achieves a 76% code coverage of the existing Pythong ocde package. (Code coverage isn't an absolute measure - it doesn't measure correctness by itself, e.g. in the registration server it doesn't check for the validity of the responses).

The primary motivation for this is larger refactors that are coming down the line, as well as code hygiene in general. (I thought it'd be best to start with tests :). Between the test suite, static typing, code coverage, and other linter errors, I've found a number of real bugs in the codebase -- a couple are in tests marked with "xfail" but there are a few others. More on that soon :)

After this (hopefully) gets merged, it'd be neat if we could also setup some kind of CI (GitHub Actions, Travis etc. - pick your poison!) to catch regressions in PRs going forward.

The Python scripts are now loosely coupled (independent scripts) but
they sometimes share code (e.g. pad/unpad/encrypt/decrypt), and other
times even import from each other (in the case of smartconfig). They
also often include code to make them importable (if __name__ ==
"__main__").

However, they currently are not structured as a package. Move them all
to a package called "smarthack" and into valid module filenames (no
dashes!) so that they can be importable.

This allows one to do e.g.
    from smarthack import registration

This is the first step towards a larger codebase refactor.
@kueblc
Copy link
Collaborator

kueblc commented Jan 9, 2020

Hi @paravoid, thanks for your PR! It looks like some pretty significant changes, it may take me some time to review this. In the future please open an issue to discuss any big changes before you invest too much time. There are a number of outstanding branches that may conflict with some of the changes you've presented here, and a larger refactor taking place behind the scenes.

@paravoid
Copy link
Author

paravoid commented Jan 9, 2020

Thanks! The changes here are really not very significant - it's just an mv + ~15 lines of small code changes for the test commit. The tests are all new files, and thus should not conflict with anything else.

That said... I have a ton of major changes queued up. Should I file a single new issue to capture all of them?

Add a basic tox.ini file, that applies a battery of tests, namely:
  * pytest (test suite) against python3.6 and python3.7
  * pytest-cov (code coverage)
  * flake8 (basic) plus the plugins import-order and docstrings (pep8, linting)
  * pylint (linting)
  * black (automatic code formatting)
  * mypy (type check), in semi-strict mode

As the codebase is (obviously) far from being compliant, add a top-level
"whitelist" with files/directories that we consider ready and that will
be adding to with subsequent commits.
Initial effort of unit-testing the codebase, starting with a test for
smarthack.discovery. It currently reveals a bunch of real errors, with
encrypted transport failing and masked by "except: pass" (to be fixed in
a subsequent commit).
Still rudimentary (e.g. doesn't check replies), but still covers 86% of
the codebase and has found a real bug already (namely: encrypted packets
are not being decrypted).
Rudamentary, as it only checks gen_psk() and not ssl.wrap_socket (and as
such won't catch issues like sslpsk#16), but the best we can do for now
and without modifying the code itself.
@alexyao2015
Copy link

This looks great! Are there plans on merging/implementing something similar? I agree that the current code is in need of a refactor.

@kueblc
Copy link
Collaborator

kueblc commented Nov 4, 2020

@alexyao2015 tuya-convert is fairly stable at the moment, while not the most organized, it is functional. I believe the priorities of this project are with keeping up with Tuya firmware changes, and not necessarily rewriting or refactoring what is already working.

That said, feel free to pitch specific improvements and why you believe they are needed. I would be happy to accept incremental improvements so long as they fit the rest of the project and provide a clear benefit.

@alexyao2015
Copy link

Totally makes sense! The main issue I had was with installing/using it. I wanted to use the docker image, but ran into pretty massive roadbumps on my raspberry pi zero w as the base image wasn't available. I would suggest potentially using debian as the base with the s6 overlay, preinstalling all requirements, and uploading to docker hub so there is no need to have the user build it. It would simplify the installation and usage a lot.

I personally had to manually create a container and install all requirements, however I didn't have time to make a complete dockerfile for it.

@ccrisan
Copy link

ccrisan commented Nov 4, 2020

Totally makes sense! The main issue I had was with installing/using it. I wanted to use the docker image, but ran into pretty massive roadbumps on my raspberry pi zero w as the base image wasn't available. I would suggest potentially using debian as the base with the s6 overlay, preinstalling all requirements, and uploading to docker hub so there is no need to have the user build it. It would simplify the installation and usage a lot.

I personally had to manually create a container and install all requirements, however I didn't have time to make a complete dockerfile for it.

If you just need a quick Tuya Convert setup on your Pi without messing around with the system each time you need it, you can use Tuya Convert OS, an OS that I put together especially for Tuya Convert.

I keep a dedicated SD card around, just for the purpose of running this OS and quickly flash my devices.

@alexyao2015
Copy link

Hmm that's a nifty project. I only happened to have a raspberry pi zero w laying around, so I wouldn't be able to use that. Anyways, with a proper docker image and the correct scripts to automatically disconnect from wifi automatically, it really isn't that difficult.

@ccrisan
Copy link

ccrisan commented Nov 5, 2020

I only happened to have a raspberry pi zero w laying around, so I wouldn't be able to use that.

@alexyao2015 it may actually work on a RPi Zero W; it's based on Raspbian after all. You could give it a try and let me know, so that I can update the hardware requirements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants