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

Python unit testing requirement #2

Open
jared321 opened this issue Aug 29, 2023 · 2 comments
Open

Python unit testing requirement #2

jared321 opened this issue Aug 29, 2023 · 2 comments
Assignees

Comments

@jared321
Copy link
Contributor

The current template repo has two python packages, both of which use python's unittest framework. In mytemplate, this includes two sub-packages that each uses unittest. However, pytest is another framework that others might prefer to use (or are already using).

What are the POptUS requirements for unit testing within a python package, across python packages within a particular repo, and across all python packages in the POptUS organization?

My proposed requirements are:

  1. Each python sub-package shall be able to use the the unit testing framework of their choice (e.g., unittest, pytest).
  2. Each python package shall be constructed and maintained in such a way that all the tests from the main package and from all sub-packages (regardless of which unit test framework they use) can be effectively grouped into a single test suite that users can run via <package>.test() and with a single command to tox (e.g., tox -r -e nocoverage).

If these are the desired requirements, then this template should be updated so that mytemplate/subA uses unittest and mytemplate/subB uses pytest. This is necessary to prove that these requirements can be satisfied and to provide a concrete demonstration of how to achieve it.

@jmlarson1 @wildsm @mmenickelly Any thoughts on these requirements?

@jared321 jared321 self-assigned this Aug 29, 2023
@jmlarson1
Copy link

Thank you for the help on testing.

  1. I find pytest to be more common, but I have been pleased with what's working with unittest. If unittest works, why support pytest too? (It seems like giving ourselves more work to maintain, but maybe supporting general testing infrastructure will make future dev work easier.)
  2. I think the goal of having tests for each sub-package to be separate is logical (and makes my development workflow easier.)

@jared321
Copy link
Contributor Author

@jmlarson1 I'm glad to hear that you are happy with unittest. I continue to be happy with it as well. One benefit of using unittest that I should mention is that pytest can run tests written in unittest, whereas I do not believe that the opposite is true. This has been one motivation for me to continue using unittest.
https://docs.pytest.org/en/7.1.x/how-to/unittest.html

One possible argument against unittest is that writing a test for unittest that is just a single python function is possible but the function won't have access to full functionality such as the self.assert* family of tests. It looks like you can only use the standard assert.
https://docs.python.org/3/library/unittest.html#re-using-old-test-code
You'll see at that link that they also do not recommend using this part of the unittest interface.

Thoughts?

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

No branches or pull requests

2 participants