TST: Fix some bare pytest raises

[ShaharNaveh]

• ref [Good first issue] TST: Disallow bare pytest.raises #30999
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

Follow up for #30998

[WillAyd]

@MomIsBestFriend might be misreading but I don't really understand this PR. Is this de-parametrizing an existing test?

[ShaharNaveh]

@MomIsBestFriend might be misreading but I don't really understand this PR. Is this de-parametrizing an existing test?

Correct, because I had troubles in #30998 to put a correct "match" value (trying to remove bare pytest raises statement).

I was having something that looked kinda like this:

msg = (
              r"cannot perform __pow\_\_ with this index type: DatetimeArray|"
              r"cannot perform __mod\_\_ with this index type: DatetimeArray|"
              r"cannot perform __truediv\_\_ with this index type: DatetimeArray|"
              r"cannot perform __mul\_\_ with this index type: DatetimeArray|"
              r"cannot perform __pow\_\_ with this index type: TimedeltaArray|"
               "ufunc 'multiply' cannot use operands with types dtype"
              r"\('<m8\[ns\]'\) and dtype\('<m8\[ns\]'\)|"
                "cannot add DatetimeArray and Timestamp"
         )

(That value did not work)

I think, IMO the "de-parameterization" functions is more readable and maintainable (And I was able to fix the bare pytests raises statement).

[WillAyd]

I think should keep the original parametrization. The error messages are of secondary importance so don't need to be exact. You can just pick a simpler pattern like cannot (perform|add)

[ShaharNaveh]

I think should keep the original parametrization. The error messages are of secondary importance so don't need to be exact. You can just pick a simpler pattern like cannot (perform|add)

I know that msg (#31105 (comment)) can be prettier using some regex "magic".
The problem is that the parameterized test is also raising an external error message, which can be a bit trickier to "ignore" that specific message, thing that will probably that there will be the need for some nested if statements.

---

I will commit the parameterized test, with the nested if statement(s).
And just pick the one you like more :)

Also, side question, does the parameterized test is more performant? (trying to see why the de-parameterized test is less likeable)

[WillAyd]

Also, side question, does the parameterized test is more performant?

I don't think it matters but even if it did should strongly prefer parametrized tests to breaking out individually; the latter is tougher to extend and maintain over time and leads to more lapses in coverage

[ShaharNaveh]

@WillAyd You were 100% right!
it's just one if statement, and it does looks much better than the de-parameterized tests

[ShaharNaveh]

(unrelated)
If someone mention you in a regular comment of a PR/issue that was merge/closed, would you still get notified?

[WillAyd]

Thanks @MomIsBestFriend and answer to your question depends on per-user settings