I'm a software engineer for a startup called OnShift. I use gRPC and python daily to design and implement microservices. In my spare time I enjoy golfing and woodworking.
My beef with using unittest.TestCase is that if you use TestCase assertions, your code is not very pythonic. When you use pytest as your test runner, you can use the built in python assert and pytest will override assert with its own built in assertions.
For example:
thing = True assert thing vs self.assertTrue(thing)
items = [1, 2, 3, 4] assert 1 in items vs self.assertIn(1, items)
I think the tests look cleaner when it's pure python code and you don't have to think about or look up what assertion methods are available to you.
I like the xunit style for the test organisation, the well-defined life-cycle (setUp, tearDown (ignoring the un-Pythonic camel-casing)) and the portability.
Yes, you can organise your tests in a module but it's likely you'll have multiple functions and classes in a module and I like to have a corresponding test module with a TestCase class per function/class.
You can use the pytest life-cycle decorators on functions but that then ties you more closely to pytest. Using unittest allows you to switch runners more easily.
I have stopped using the assert* methods on self though - I use plain assert statements which give nicer output from pytest.
My beef with using
unittest.TestCaseis that if you useTestCaseassertions, your code is not very pythonic. When you usepytestas your test runner, you can use the built in pythonassertandpytestwill overrideassertwith its own built in assertions.For example:
thing = Trueassert thingvsself.assertTrue(thing)items = [1, 2, 3, 4]assert 1 in itemsvsself.assertIn(1, items)I think the tests look cleaner when it's pure python code and you don't have to think about or look up what assertion methods are available to you.
pytestalso allows you to run tests in parallel if you wantI like the xunit style for the test organisation, the well-defined life-cycle (
setUp,tearDown(ignoring the un-Pythonic camel-casing)) and the portability.Yes, you can organise your tests in a module but it's likely you'll have multiple functions and classes in a module and I like to have a corresponding test module with a
TestCaseclass per function/class.You can use the pytest life-cycle decorators on functions but that then ties you more closely to pytest. Using
unittestallows you to switch runners more easily.I have stopped using the
assert*methods onselfthough - I use plainassertstatements which give nicer output from pytest.Good compromise :)