fossasia / pslab-python

Python Library for PSLab Desktop: https://pslab.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Refactor code base to release on pip

CloudyPadmal opened this issue · comments

We need to give proper reformatting and documentation before we make a release on pip to make it super easy to install pslab-python

Can i work on this??

Go ahead. I'm currently refactoring the logic analyzer functionality, so if you want you can take a look at, for example, the waveform generator, the power supply, the multimeter, the motor controller, or the I2C or SPI peripherals.

Ok thanks

Some pointers:

  • A lot of functionality is currently concentrated in the ScienceLab class. It's too big, so a good start is to move functionality out of there to its own module.
  • The SENSORS subpackage is another good candidate for refactorization. It may be possible to write a common abstract base class for all sensors.
  • We currently do not have a lot of unit tests. However, any new or refactored functionality should have unit tests written with unittest.
  • For code style, adhere to flake8 and black, with PEP8 as the overarching style guide.
  • Every public interface must be documented. Use Numpy-style docstrings, and adhere to PEP257.

as this is my first time can you tell me the codebase used?

any new or refactored functionality should have unit tests written with unittest

Any reason that unittest is preferred over pytest?

With pytest, we can incorporate other checking like flake8, doctest into one run. Code for pytest also look nicer with pep8-compliant function names (setup instead of setUp, teardown instead of teardown), and shorter assert calls.

Any reason that unittest is preferred over pytest?

With pytest, we can incorporate other checking like flake8, doctest into one run. Code for pytest also look nicer with pep8-compliant function names (setup instead of setUp, teardown instead of teardown), and shorter assert calls.

I agree, and generally prefer pytest to unittest. However, this project relies heavily on pyserial for communication, which means we need to mock the serial connection during testing. For mocking, specifically, I find unittest.mock superior to pytest's monkeypatch.

as this is my first time can you tell me the codebase used?

I'm not sure I understand your question. The codebase is what is contained in this repository. Can you be more specific?

Note you can use unittest.mock together with pytest as well. Either directly, or via the pytest-mock plugin. I'd recommend the latter as it nicely integrates things with a mocker pytest fixture, which then undoes the patching properly without having to rely on a unittest.mock.patch decorator.

FWIW I personally prefer monkeypatch or pre-made mock libraries (e.g. responses for the requests HTTP library) because unittest.mock objects can be hard to configure to act like the real thing, and without proper care can allow things which wouldn't actually work against the real object.

For PySerial there doesn't seem to be such a library available in a ready-to-use state, but there are a couple of attempts which might work out:

Alternatively, socat (Linux) or com0com can be used for end2end tests against a real (virtual) serial port, but that requires some more setup before being able to run the testsuite, so often isn't ideal either.

tl;dr: Use pytest-mock 🙂

Yes, if the only reason you are tied with unittest is unittest.mock, then just use pytest + pytest-mock combo.

Interesting, I was not aware of pytest-mock. Thanks for the suggestion, I'll look into it!

can I work on the documentation and reformatting?

Hello @AbhinavMathur29pers , sure you can. Please go ahead 👍

Closing this issue since pslab-python is now on pypi. Code refactorization is still in progress and is tracked in #127.