TST: pytest.raises vs. tm.assert_raises_regex

[gfyoung]

I'm wondering whether we should explicitly say in the docs that we prefer tm.assert_raises_regex over pytest.raises unless there is no error message to provide. The former is a lot more informative from a dev-perspective as to why certain code should fail.

Thoughts?

(If we can agree that we do prefer the former, I also move to convert some of the tests to use tm.assert_raises_regex instead of pytest.raises).

[jreback]

I don't think this is necessary to always check the actual content of the error, unless the content of the message is relevant (maybe to distinguish cases).

[gfyoung]

@jreback : Fair enough, but I think in many cases, we can though. One of my arguments for using tm.assert_raises_regex is that you can get a better idea of WHY code should fail beyond just the exception being raised.

So sure, I don't think all of them need to be converted, but I still do think tm.assert_raises_regex should be preferred by default. How does that sound?

[TomAugspurger]

FWIW, I would like to avoid calling pytest-specific methods where possible, to make a migration away from pytest easier in the far future, if that's ever necessary.

We could add a tm.assert_raises context manager that simply wraps pytest.raises at the moment.

[gfyoung]

@TomAugspurger : That is possible, though tm.assert_raises_regex(exc, None) also does the trick.

[jreback]

FWIW, I would like to avoid calling pytest-specific methods where possible, to make a migration away from pytest easier in the far future, if that's ever necessary.

I don't think this is a good reason. The good reason is that simply changing an error message can cause failures which are not immediately obvious (of course you want things to fail, but this mean that your regext could be too strict).

[gfyoung]

@jreback : I think @TomAugspurger was somewhat separate from the main discussion. That being said, what you said is one reason why I think we should prefer tm.assert_raises_regex by default.

[gfyoung]

I'm going to close this, since I think there is sufficient discussion on this matter (at least for myself 😄). Can always revisit if need be.