Re:Stop requiring only one assertion per unit test: Multiple...
by olex on Saturday November 05, 2022 @07:26AM
(#33480428)
Ok, in this case a parametrized test is not the best approach, I agree. But I would still want to avoid the for-each and "failing fast". One approach would be to gather the required attributes in an array or a struct of some sort, and then do a single assert comparison with an expected value, showing all the differences at once. However, this requires the assertion framework to be able to make such a comparison and return a nicely readable error message, ideally with a diff.
[ Parent
| on HN ]
Re:Stop requiring only one assertion per unit test: Multiple...
by dd82 on Saturday November 05, 2022 @07:31AM
(#33480454)
Right, and not many actually do. with python and pytest, you could leverage difflib, but that's an additional thing that adds unnecessary complexity. My approach is simple enough, good enough, and doesn't require additional fudging around with the basics of the language's test libs.
also,
>your example stops on the first one that fails, and does not evaluate the others after that.
I would argue this is desirable behavior. there are soft checks, ie, https://pypi.org/project/pytest-check/, that basically replace assertions as raised exceptions and do your approach. But I do want my tests to raise errors at the point of failure when a change occurs. If there's alot of changes occurring, that raises larger questions of "why" and "is the way we're executing this change a good one"?