Ask HN: What is your preferred Python 3 testing framework?

I've never heard of that term being used but parametrize helps in situations where:

a) You have a slew of test inputs that all need to be tested through the same function, but you don't want to duplicate code.

b) You want something like "test with every combination of [x,y,z] for parameter a and [j,k,l] for parameter b". This is probably what the grandparent is referring to.

c)You have an even more complicated scheme, which you can define.

This is better than just having a for loop over a pre-generated list of parameters and calling a function with the same assertions, because pytest sees and handles them as separate but related test cases (e.g. when reporting errors, crash handling, fixtures, etc)

You can use attrs validators for it, though it's not maximally concise. (i.e. you need functions declared, but it's easy to reuse them.)

http://www.attrs.org/en/stable/examples.html#validators

Also, the next attrs release looks like it's getting some support for PEP484 type hinting annotations, but I don't know the details beyond having glanced at some pull requests. So it might get simpler in the future. If so, that'd make it easy to trust the type-validation, and just have the range check as a custom validator.

How is pytest superior?

I used unittest for ages and put off trying pytest for far too long because "unittest ships with Python, and it's good enough". Then I finally gave pytest a solid chance, and now I'm never going back.

I love, LOVE, L-O-V-E explicitly passing in fixtures to individual tests, rather than trying to going my tests into "stuff that needs this fixture", and "tests that need that setUp instead", and "things that need some of both ClassA's setUp and ClassB's setUp so let's inherit from both". That was a freaking nightmare that I ran into all the time.

Suppose ClassA sets up a database connection and deletes test data out of it afterward. That's kind of expensive, so you only want to use its fixtures when you actually need them. ClassB does the same but for a remote API. You end up clumping all your DB tests under ClassA and all your API tests under ClassB. Fair enough. But over time ClassA also ends up tests that don't actually hit the database, but they're so logically associated with the other tests in there that you toss them in anyway. And ClassB accretes tests like "assert that parameters are valid before hitting the API", and you're setUp'ing and tearDown'ing on those anyway even though you don't strictly need to. Fine, whatever - there aren't that many so it's not terribly bad. But now you want to write some tests that fetch from the DB and make API calls so now you have to subclass ClassA and ClassB so that you get a covering set of fixtures, and invariably they won't play nicely somehow, and everything just got infinitely more complicated. Ugh.

Compare the above with having a "db" fixture and an "api" fixture. Tests that need a database are defined like "def test_fetch_one_record(db)". Tests that need an API look like "def test_get_remote_data(api)". Need to use both? "def test_move_database_to_service(db, api)". The first time I was able to use that pattern in some existing code, I almost cried tears of happiness."

Also, I don't ever want to write "self.assertNotEqual(a, b)" instead of "assert a != b" again, especially when pytest gives much more information about the provenance of both a and b.

To me, using unittest instead of pytest is exactly like using urllib instead of Requests. You might legitimately want to sometimes, but those cases are very few and far between. Most of the time you're just making your life more difficult for no gain.

That's a different problem, though admittedly I was not very precise. (And by 'feels like typed', I meant feels closer to something like Haskell or OCaml than having eg Java as my target.)

Even the best constructor magic in Python will struggle helping you verify the types of your functions.