issue_comments

Looks like these

https://data-apis.org/array-api-tests/.

use these

experimental array api strategies

Would that be useful here?

I think they are complementary. In theory if xarray supports the array API standard and a library passes all the data array API tests, then it should also pass all of xarray's tests (rendering the latter uneccessary). But in practice I think the tests here would still be useful, if only for the possible case of libraries that don't fully meet the API standard yet would still work fine in xarray.

@asmeurer recently pointed me to https://data-apis.org/array-api-tests/. Would that be useful here?

there's also the experimental array api strategies built into hypothesis

Another thing that might be useful is the hypothesis strategies in the test suite for the array API consortium standard (cc @keewis).

Typing duck array is also a little challenging I find

Thanks @Illviljan - I was literally just thinking about that here.

Typing duck array is also a little challenging I find, we pretty much only do Any at the moment. I found some nice references and discussions that might be interesting for this: https://github.com/pmeier/array-protocol https://github.com/data-apis/array-api/issues/229

you should already be able to specify a hypothesis strategy to create e.g. a random awkward array

Sounds good!

or maybe it should be just check?

Yes just check probably.

However, maybe we should just not use parametrize but instead define separate functions for each reduce operation?

But then the user writing the test code would have to write one of their own tests per xarray method wouldn't they? I think we should avoid putting that much work on them if we can. I think your current approach seems fine so far...

the pint tests use old versions of the conversion functions from pint-xarray

That's basically technical debt, so we should make a point to remove them from xarray eventually.

the tests for pint seem to increase the total test coverage of xarray https://github.com/pydata/xarray/pull/5692#issuecomment-1040002844. I guess that just means we'd have to improve the rest of the testsuite?

So long as @benbovy (or someone) writes new tests to cover the bugs that were revealed then this is fine.

with the implementation in #4972 you should already be able to specify a hypothesis strategy to create e.g. a random awkward array. Same with dask or other parallel computing frameworks: if you can construct a hypothesis strategy for them the testing framework should be able to use that. check_reduce (or maybe it should be just check?) should allow customizing the comparison (or actually, that's the entire test code at the moment), so putting compute (or todense / get) calls should be easy.

For setup and teardown I think we could use pytest fixtures (and apply them automatically to each function). However, maybe we should just not use parametrize but instead define separate functions for each reduce operation? Then it would be possible to override that manually. As far as I remember I chose not to do that because tests that only delegate to super().test_function() just are not great design – if we can think of a way to do that while avoiding those kinds of test redefinitions I'd be happy with that (and then we could get rid of the apply_marks function which is a ugly hack of pytest internals).

I agree that moving the array library tests to dedicated repositories makes a lot sense (for example, the pint tests use old versions of the conversion functions from pint-xarray), but note that at the moment the tests for pint seem to increase the total test coverage of xarray a bit. I guess that just means we'd have to improve the rest of the testsuite?