Stop requiring only one assertion per unit test: Multiple assertions are fine

Re:Stop requiring only one assertion per unit test: Multiple... by danuker on Saturday November 05, 2022 @07:02AM (#33480265)

We are using unittest.

But thanks for bringing it up, it seems it also has "subtest" support, which might be easier than interpolating the error message in some cases:

https://docs.python.org/3/library/unittest.html#distinguishi...

[ Parent | on HN ]

Re:Stop requiring only one assertion per unit test: Multiple... by Dunedan on Saturday November 05, 2022 @08:16AM (#33480723)

There is also `parameterized` [1] if you want to do it by using decorators.

[1]: https://pypi.org/project/parameterized/

[ Parent | on HN ]

Re:Stop requiring only one assertion per unit test: Multiple... by masklinn on Saturday November 05, 2022 @08:20AM (#33480751)

> We are using unittest.

Unless you need the library style in order to drive it, switch to pytest. Seriously.

- assert rewriting is stellar, so much more comfortable than having to find the right assert* method, and tell people they're using the wrong one in reviews

- runner is a lot more practical and flexible: marks, -k, --lf, --sw, ...

- extensions further add flexibility e.g. timeouts, maxfail, xdist (though it has a few drawbacks)

- no need for classes (you can have them, mind, but if functions are sufficient, you can use functions)

- fixtures > setup/teardown

- parameterized tests

[ Parent | on HN ]

Re:Stop requiring only one assertion per unit test: Multiple... by jjgreen on Saturday November 05, 2022 @08:47AM (#33480891)

You mean "subTest", I switched to pytest just to get away from the camel (and it's in the standard library!)

[ Parent | on HN ]

Re:Stop requiring only one assertion per unit test: Multiple... by ericvsmith on Saturday November 05, 2022 @09:47AM (#33481439)

Came here to mention unittest.subtest. It's for exactly this case.

[ Parent | on HN ]