Unit Test Results

6 files           6 suites   51m 7s :stopwatch: 16 290 tests 14 551 :heavy_check_mark: 1 739 :zzz: 0 :x: 90 936 runs  82 738 :heavy_check_mark: 8 198 :zzz: 0 :x:

Results for commit add9b1ae.

:recycle: This comment has been updated with latest results.

Hi @Illviljan @keewis,

I have added tests and marked them as xfail

Accoriding to pytest docs

A skip means that you expect your test to pass only if some conditions are met, otherwise pytest should skip running the test altogether. Common examples are skipping windows-only tests on non-windows platforms, or skipping tests that depend on an external resource which is not available at the moment (for example a database).

An xfail means that you expect a test to fail for some reason. A common example is a test for a feature not yet implemented, or a bug not yet fixed. When a test passes despite being expected to fail (marked with pytest.mark.xfail), it’s an xpass and will be reported in the test summary.

This case seems exactly what xfail is meant for. But feel free to change this.

Do the slice plots work with non-dimension coordinates? If so, we should maybe add a test with pint for that, too: units in non-dimension coordinates are not stripped.

It seems so, but it raises a pint warning despite the code producing the intended figure:

```python import xarray as xr import numpy as np import matplotlib.pyplot as plt import pytest pint = pytest.importorskip("pint") unit_registry = pint.UnitRegistry(force_ndarray=True)

coord_unit, coord_attrs = (unit_registry.m, {})

def test_units_in_slice_line_plot_labels_isel(): arr = xr.DataArray( name="var_a", data=np.array([[1, 2], [3, 4]]), coords=dict( a=("x", np.array([5, 6]) * coord_unit, coord_attrs), b=("y", np.array([7, 8])), ), dims=("x", "y"), ) arr.isel(x=0).plot(marker="o") assert plt.gca().get_title() == "a = 5 [meter]" return arr

test_units_in_slice_line_plot_labels_isel() ```

I would appreciate a lot if we keep the scope of this PR to what I have contributed so far, I am running out of bandwidth in the project I am involved and won't be able to add much more to this PR.

Kind regards, Victor

Just checked and this cannot be tested for pint units, there is already a comment in there explaining this:

```python

TODO make coord a Quantity once unit-aware indexes supported"

``` Since the slice units come from a coordinate these units can't be pint units (at least not yet).

I added a new test for the units in the title of a slice line plot, also added the same comment about pint units.

Who should I ping for the PR approval?

This is great, thanks @caenrigen !

It just needs a couple of tests - ideally one for basic behaviour like you've shown in your example (which should probably live here), and another checking that it works with pint units like we added in #5561.

Hi @TomNicholas!

Thank you for the input and guidance, will work on adding the tests 🙂

Cheers