TST: Add more tests for np.pad

[eric-wieser]

Extracted from #11358 + the addition of an xfail marker.

[hmaarrfk]

I think it is best if we keep this test just for 'mean'. The other functions will not suffer from this bug.

[eric-wieser]

Why not test them anyway?

[hmaarrfk]

I get it, but this is very convoluted targeted test.
I think it can definitely make use of a "in source" comment summarizing the issue.

We are essentially testing the implementation of the algorithm as well as the peculiarities of floating point numbers. it is easy to understand why maximum and minimum are not likely to suffer from this bug. median will also not suffer from this.

If we want to test the general behaviour for all 4 other modes, I think it is better to have them in a more general different test and keep this particular test very targeted.

[lagru]

Would this be a good opportunity to include a test covering the behavior described in #11358 (comment):

>>> from fractions import Fraction
>>> np.pad([Fraction(10)], (2, 2), mode='linear_ramp', end_values=Fraction(1,2))
array([0.5, 5.25, Fraction(10, 1), 5.25, 0.5], dtype=object)

as well?

[eric-wieser]

@lagru: I don't thing the current output is really correct for that either. I suppose I could add another xfailing test for that.

[lagru]

@eric-wieser That is the behavior of the old pad function.

Would you expect the output to be array([Fraction(1, 2), Fraction(21,4), Fraction(10, 1), Fraction(21,4), Fraction(1, 2)], dtype=object)?

[eric-wieser]

@lagru: Indeed it is, and yes I would. I think the best option here is @pytest.mark.xfail(raises=AssertionError), so that we can allow the output to be suboptimal, but still make the test catch cases when a new error is raised.

[eric-wieser]

Added that test, and updated the comments in the other test

[charris]

Thanks Eric.