Add automated testing of translations.py
#305
Assignees
Milestone
Comments
This was referenced May 8, 2023
Eric-Arellano
added a commit
that referenced
this issue
May 11, 2023
Closes #305. ## Both Pytest and Jest tests We now have tests both in Python and JavaScript. That is because this is a multilingual repository, and we can only test code in the language it's written in. The tests are organized into `tests/{js,py}`. ## Changes `tox -e py` and adds `tox -e docs` Before, `tox -e py` was used to build example_docs. But that is different than every single Qiskit project, where `tox -e py` normally runs tests and you use `tox -e docs` to build the docs. This PR aligns us with the greater Qiskit ecosystem. ## Uses Pytest rather than unittest Most Qiskit projects use unittest/stestr (a way to parallelize unittest), although a few have switched to Pytest: Yeah, there are a few projects using Pytest but indeed most use unittest/stestr ``` ❯ rg pytest -g '*.txt' -l qiskit-ionq/requirements-test.txt mthree/requirements-dev.txt qiskit-qasm3-import/requirements-dev.txt qiskit-metal/requirements-dev.txt ``` If I remember correctly from when I first joined the project, Jake (or Matthew) was interested in eventually migrating more of Qiskit to Pytest and that they don't love stestr/unittest. But it's a bigger migration to do that I've found that Pytest in general is more ergonomic & also more flexible than unittest. For example, it has neat support for parametrization to make it easy to write several similar tests. And it's easier for developers to use because you only ever need to use `assert <some condition>`, rather than figuring out which to use between `self.assertEqual` vs `self.assertTrue` vs `self.assertContains` etc. Pytest will make the output of the `assert` useful for you automatically.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Follow up to #302.
The text was updated successfully, but these errors were encountered: