pytest:<p><a href="https://docs.pytest.org/en/latest/" rel="nofollow">https://docs.pytest.org/en/latest/</a><p>The dependency injection for fixtures is somewhat of a magical entity, but overall I've found it's the most efficient way to hammer out good tests on the standard unit/integration test spectrum. The default mode of operation doesn't even require importing pytest: Just write files named ending with `_test.py`, functions starting with `test`, and bare bones assertions. `yield_fixture` works well with the typical mock-and-assert-on python test pattern.<p>Plenty of plugins out there for more exotic features, like asyncio, parallelization (though test parallelization tends to be much more problematic beyond "run tests at the same time"), output to <format>, etc too.
The company I work for uses standard unittest [0] library from Python. This library helps you to test defined functions in your Python program. For each defined function, you can set different cases to test (positive and negative cases). We also use coverage [1] to see code coverage and report. Report is usually reported to HTML because we can check the missing part of code (the flow of our logic program).<p>[0]: <a href="https://docs.python.org/3/library/unittest.html" rel="nofollow">https://docs.python.org/3/library/unittest.html</a><p>[1]: <a href="https://pypi.python.org/pypi/coverage" rel="nofollow">https://pypi.python.org/pypi/coverage</a>
Anything but pytest is good.<p>Pytest is full of magic and can be horrendous for a newcomer to your team. You can't work out what is happening just by reading the tests, you have to know how pytest works.<p>Also, when something breaks in pytest, all the magic means that it can be very hard to work out what is happening.
import unittest<p>Used for CI in <a href="https://github.com/serprex/aespython" rel="nofollow">https://github.com/serprex/aespython</a>