unittest with https://github.com/kislyuk/ensure
Ask HN: What is your preferred Python 3 testing framework?
21–30 of 46 posts
Re: Ask HN: What is your preferred Python 3 testing framework?
#22currently 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.
If you want to really make Python feel like a typed language, and still be idiomatically Pythonic, learn to write constructors that raise ValueError in appropriate ways.
Re: Ask HN: What is your preferred Python 3 testing framework?
#23Earlier quoted context omitted.
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
> pytest fixtures don't have that issue, as they're only run when you include the fixture for DI
I don't see how that prevents any of the basic problems raised in the article.
Re: Ask HN: What is your preferred Python 3 testing framework?
#24Earlier quoted context omitted.
Using hypothesis makes Python feel almost like a typed language for me.
If you want to really make Python feel like a typed language, and still be idiomatically Pythonic, learn to write constructors that raise ValueError in appropriate ways.
Is there a good way to do that that doesn't involve a bunch of if-this-or-that-then-raise ~boilerplate in your constructors? e.g., is there some nice library that will let me put annotations like "must be a list of at least two items" or "must be an integer between 0 and 99" with a more concise syntax?
Re: Ask HN: What is your preferred Python 3 testing framework?
#25Earlier quoted context omitted.
If you want to really make Python feel like a typed language, and still be idiomatically Pythonic, learn to write constructors that raise ValueError in appropriate ways.
Is there a good way to do that that doesn't involve a bunch of if-this-or-that-then-raise ~boilerplate in your constructors? e.g., is there some nice library that will let me put annotations like "must be a list of at least two items" or "must be an integer between 0 and 99" with a more concise syntax?
Ummm, maybe? There seem to be libraries for everything, but I do it manually. The constructors become "non-trivial", but not overly-complicated, and it pays off in simpler, more robust code elsewhere.
So my code would be something like:
class Foo:
def __init__(self, x, y=None):
if y is None:
x_ = x.x
y = x.y
self.x = int(x_)
if self.x 99:
raise ValueError('x must be in range 0..99')
if len(y) 2')
self.y = y
You can say:
f = Foo(1,['a','b'])
f = Foo(1,('a','b', 3))
f = Foo("42", "bar")
f2 = Foo(f)
So whether or not the performance impact and extra code are worth it probably varies from project to project.
Re: Ask HN: What is your preferred Python 3 testing framework?
#26Earlier quoted context omitted.
Using hypothesis makes Python feel almost like a typed language for me.
If you want to really make Python feel like a typed language, and still be idiomatically Pythonic, learn to write constructors that raise ValueError in appropriate ways.
Or use type annotations and mypy/typeguard.
Re: Ask HN: What is your preferred Python 3 testing framework?
#27Earlier quoted context omitted.
pytest fixtures don't have that issue, as they're only run when you include the fixture for DI
> pytest fixtures don't have that issue, as they're only run when you include the fixture for DI I don't see how that prevents any of the basic problems raised in the article.
py.test avoids XUnit or unittest style class-based tests for this reason (though it will run them if you insist). It opts for simple test functions instead. Fixtures are passed in explicitly as parameters rather than implicitly as class members or whatnot. The result of all this is quite similar to what the author proposes.
Re: Ask HN: What is your preferred Python 3 testing framework?
#28pytest: 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_…
Also pytest have pytest-bdd[1] for BDD, with that in mind you can use pytest for unit tests and behave tests, with only one runner is just awesome (because you write your fixtures only once)
Also good to mention pytest-xdist[2] for distributed testing...
Re: Ask HN: What is your preferred Python 3 testing framework?
#29pytest: 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_…
My favorite feature of pytest is pytest.mark.parametrize, which makes it easy to do table driven testing.
what is "table driven testing"?
Re: Ask HN: What is your preferred Python 3 testing framework?
#30pytest: 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_…
I'll enthusiastically second py.test. It's well documented, well supported, and well thought out. More importantly though, the details are just brilliantly done.
For example: showing the values of local variables in an error traceback always saves me a ton of time. I don't know why this isn't the default option. Alternatively, you can pass --pdb to just run the debugger exactly when a test crashes, so you can inspect the contents.
Another example is how it prints out details on assertions (e.g. "the left was this and the right was this") and not just "AssertionError". On top of that, for complex data structures, it will diff them and point out exactly what parts of the structure are matching and what parts are not matching, which again saves a ton of time from firing up a debugger and doing it by hand.
For more esoteric options, I like this pycon talk: https://www.youtube.com/watch?v=jmsk1QZQEvQ