[pytest] Initial work towards testing tools

[gbalke]

This adds unit tests to the base level tools. These tests are by no means complete but they establish a baseline. There's also some thrown in adjustments to importing, formatting, and a loop helper to improve loop metrics.

Vaguely on the path of #38. Wanted to make it easier to change stuff while on the go as I'm not always in front of hardware.

[wuphilipp]

looks good to me! lots of files looked auto formatted so i did not look very closely at those

[gbalke]

@wuphilipp I started using an autoformatter (yapf) and plan on introducing it to the python code via another PR. If you think it'd make sense to do this before this PR, to reduce the diff, I can make that work!

[brentyi]

realize this code isn't part of this PR, but this might be easier with an f-string!

f"{time.time()}, {closed_pos}, {opened_pos}, {temperature}, {max_current}\n"

[brentyi]

these on-the-fly class declarations feel a little bit hacky to me?

maybe consider something like:

• Move the Args dataclass to calibrate_encoder.py, which would let you properly hint def action(args): => def action(args: Args):
• In calibrate_encoder.py: replace the ArgumentParser code in parser_args() with something like datargs; this should be ~1 line
• Import calibrate_encoder.Args in the test file, and just instantiate it instead of re-defining all of the fields

would cut down some redundant code + make static analysis and autocomplete usable for arguments!

[gbalke]

Ooooh https://github.com/roee30/datargs#sub-commands. Seems reasonable as it can still address #38.

[gbalke]

I think a change of this scale (dropping argparse) should be handled when resolving #38. For now, this is a getting off the ground sort of PR. I think the discussions have brought up lots of good points to resolve in follow-up PRs.

[brentyi]

As a note on autoformatting (if you're not particularly attached to yapf yet), maybe also take a look at black?

I think Philipp and I generally both use an isort + black workflow, which is much more aggressive than just yapf. (and probably more common for non-Google employees)

[gbalke]

As a note on autoformatting (if you're not particularly attached to yapf yet), maybe also take a look at black?

I think Philipp and I generally both use an isort + black workflow, which is much more aggressive than just yapf. (and probably more common for non-Google employees)

I'd suggest this be handled in a separate issue. I'd be happy to discuss if you'd like to put one together 😄.

[gbalke]

Merging this as soon as green CI and then I'll get started on formatting/linting @brentyi.