Open rneswold opened 1 year ago
@tiradani recently recommended Hypothesis in Slack.
I feel like I abandoned this idea because being able to test against the control system would be the most useful test. Maybe we can be a prototype for GitHub Actions testing using a Fermi-hosted runner? @mgonzal1
For unit testing we can use pytest framework, and use python-mock to mock the control system functionality.
https://docs.pytest.org/en/7.2.x/ https://pypi.org/project/pytest-mock/
Are you using any python linter? They are useful to catch some python code mistakes.
I know @beauremus has run the linter (possibly through VisualStudio) to test our code. I haven't yet but should add it to my toolset.
In our v1.x branch, you can see what I have worked on. https://github.com/fermi-controls/acsys-python/blob/v1.x/.github/workflows/python-package.yml Pytest and flake8 I know lots of folks who prefer black. I don't have a strong preference. I think I'm using flake8 because the default Python workflow template from GitHub uses it.
@beauremus said:
@tiradani recently recommended Hypothesis in Slack.
That looks interesting. I'm not sure how difficult it would be to test async
code with it. But maybe that's an issue with all test packages.
@mgonzal1 said:
For unit testing we can use pytest framework, and use python-mock to mock the control system functionality.
I like the idea of using mock-ups to test the control system interaction. Is it a problem that it requires Python 3.7+? I guess we wouldn't have to test on the CLX machines ...
Python doesn't easily let you refactor code. Simple, breaking changes can only be caught at run-time, which is frustrating. We have a small collection of scripts to see that
acsys
works, to first order. But they don't exhaustively test the modules.We should evaluate Unit Test libraries, pick one, and incorporate tests in the code so we can feel confident we haven't broke anything after adding features (or fixing other bugs!)
Has anyone had experience with testing Python libraries? Any recommendations?