4 ms·

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

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). [0]: https://docs.python.org/3/library/unittest.html https://docs.python.org/3/library/unittest.html [1]: https://pypi.python.org/pypi/coverage https://pypi.python.org/pypi/coverage

guitarbill 9y ago
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/ https://docs.djangoproject.com/en/1.11/topics/testing/
- orf 9y ago
  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*'.
  - sidlls 9y ago
    How is pytest superior?
    - orf 9y ago
      It's much more pythonic for starters, java-style camelcase is not great to look at. Fixtures are very powerful, as are parameterized tests. Assertion failures give you a lot of output to help you debug, like local variables and their values. There are a wide variety of plugins to help you test various frameworks (pytest-django, pytest-asyncio), various other plugins that plug into linters (pytest-flake8, pytest-isort). Super easy parallel tests. If you need to write something that has as few (or no) external dependencies then the standard unittest library is OK. All in all it's a bit like using urllib over requests. Sure, both work and get the job done, but one is just nicer.
kstrauser 9y ago
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.

guitarbill 9y ago

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/ https://docs.djangoproject.com/en/1.11/topics/testing/

orf 9y ago
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*'.
- sidlls 9y ago
  How is pytest superior?
  - orf 9y ago
    It's much more pythonic for starters, java-style camelcase is not great to look at. Fixtures are very powerful, as are parameterized tests. Assertion failures give you a lot of output to help you debug, like local variables and their values. There are a wide variety of plugins to help you test various frameworks (pytest-django, pytest-asyncio), various other plugins that plug into linters (pytest-flake8, pytest-isort). Super easy parallel tests. If you need to write something that has as few (or no) external dependencies then the standard unittest library is OK. All in all it's a bit like using urllib over requests. Sure, both work and get the job done, but one is just nicer.

kstrauser 9y ago

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.