Description
The slope tests (test_slope.py, test_geodesic_slope.py) cover all four backends, every boundary mode, NaN handling, constant surfaces, and several dtypes. One geometric edge case is missing: degenerate shapes where a dimension is too small for the 3x3 kernel to have an interior.
The smallest shape in the dask boundary test is (5, 5), and the cross-backend random-data test uses (2, 4). Nothing covers a 1x1 single pixel or a 1xN / Nx1 strip.
Current behavior
I probed these shapes across numpy, cupy, dask+numpy, dask+cupy, and the geodesic method. They are all handled cleanly: the planar CPU kernel loops over range(1, rows-1), which is empty when rows <= 2, so the output keeps the input shape and comes back all-NaN. Nothing raises, no shape mismatch. The geodesic path does the same.
There is no bug here. The problem is that no test pins this down, so a future change to the kernel bounds could start raising or returning the wrong shape on these inputs and no test would catch it.
Proposed change
Add a parametrized test for shapes (1, 1), (1, 5), (5, 1): planar method on all four backends, plus geodesic on numpy. Assert each call returns a DataArray matching the input shape and does not raise. Test-only, no source changes.
Found by the test-coverage sweep. Severity MEDIUM: no live defect, but a kernel-boundary contract worth locking in.
Description
The slope tests (
test_slope.py,test_geodesic_slope.py) cover all four backends, every boundary mode, NaN handling, constant surfaces, and several dtypes. One geometric edge case is missing: degenerate shapes where a dimension is too small for the 3x3 kernel to have an interior.The smallest shape in the dask boundary test is (5, 5), and the cross-backend random-data test uses (2, 4). Nothing covers a 1x1 single pixel or a 1xN / Nx1 strip.
Current behavior
I probed these shapes across numpy, cupy, dask+numpy, dask+cupy, and the geodesic method. They are all handled cleanly: the planar CPU kernel loops over
range(1, rows-1), which is empty whenrows <= 2, so the output keeps the input shape and comes back all-NaN. Nothing raises, no shape mismatch. The geodesic path does the same.There is no bug here. The problem is that no test pins this down, so a future change to the kernel bounds could start raising or returning the wrong shape on these inputs and no test would catch it.
Proposed change
Add a parametrized test for shapes (1, 1), (1, 5), (5, 1): planar method on all four backends, plus geodesic on numpy. Assert each call returns a DataArray matching the input shape and does not raise. Test-only, no source changes.
Found by the test-coverage sweep. Severity MEDIUM: no live defect, but a kernel-boundary contract worth locking in.