currently using good old unittest but with the addition of hypothesis. hypothesis is a real productivity booster.
Ask HN: What is your preferred Python 3 testing framework?
11–20 of 46 posts
Re: Ask HN: What is your preferred Python 3 testing framework?
#12tox with py.test
Re: Ask HN: What is your preferred Python 3 testing framework?
#13The 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). [0]: https…
This. Simple, well documented, works for 99% of test cases. It's also how Django does it [0].
True, it has some warts, and you need to learn about e.g. `autospec`. But for better or worse, it's the "standard" way, and for me that low barrier to entry/universality is a bigger value-add than `assert` vs `self.assertEqual`, etc.
Re: Ask HN: What is your preferred Python 3 testing framework?
#14pytest and hypothesis.
Re: Ask HN: What is your preferred Python 3 testing framework?
#15pytest and hypothesis.
Hypothesis is a worthwhile addition to any Python testing framework. As a 'QuickCheck' implementation it even beats the original Haskell version in lots of respects.
Re: Ask HN: What is your preferred Python 3 testing framework?
#16currently using good old unittest but with the addition of hypothesis. hypothesis is a real productivity booster.
Using hypothesis makes Python feel almost like a typed language for me.
Re: Ask HN: What is your preferred Python 3 testing framework?
#17[deleted]
Re: Ask HN: What is your preferred Python 3 testing framework?
#18The 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). [0]: https…
This. Simple, well documented, works for 99% of test cases. It's also how Django does it [0]. True, it has some warts, and you need to learn about e.g. `autospec`. But for better or worse, it's the "standard" way, and for me that low barrier to entry/universality is a bigger value-add than `assert` vs `self.assertEqual`, etc. [0] https://docs.djangoproject.com/en/1.11/topics/testing/
Django has some different constraints than most projects, and the test suite has been around for a long long time. In most situations pyest is a superior choice that goes beyond 'assert' Vs 'self.assert*'.
Re: Ask HN: What is your preferred Python 3 testing framework?
#19pytest: https://docs.pytest.org/en/latest/ 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_…
Pretty much anybody with big modern project i know in the industry is using pytest. It make the barrier of entry of writting tests much lower. Given how annoying it is to write test, i'd say making it even a tiny bit easier is a win. Plus fixtures scale better than tearUp and down.
Hmm I'm in the camp that believes setUp/tearDown and fixtures are not only equivalent, but both antipatterns.
This article explains it better than I can [1]
Re: Ask HN: What is your preferred Python 3 testing framework?
#20Earlier quoted context omitted.
Pretty much anybody with big modern project i know in the industry is using pytest. It make the barrier of entry of writting tests much lower. Given how annoying it is to write test, i'd say making it even a tiny bit easier is a win. Plus fixtures scale better than tearUp and down.
Hmm I'm in the camp that believes setUp/tearDown and fixtures are not only equivalent, but both antipatterns. This article explains it better than I can [1] [1] https://robots.thoughtbot.com/lets-not
pytest fixtures don't have that issue, as they're only run when you include the fixture for DI