test: make float-dtype label tests compatible with spatialdata 0.8#751
Open
timtreis wants to merge 4 commits into
Open
test: make float-dtype label tests compatible with spatialdata 0.8#751timtreis wants to merge 4 commits into
timtreis wants to merge 4 commits into
Conversation
spatialdata 0.8.0 added _validate_labels_dtype, which rejects non-integer/ non-bool label dtypes at every element-creation path (parse, the SpatialData constructor, and the Labels container all route through get_model(validate= True)). The two float-dtype label tests constructed their fixtures via Labels2DModel.parse(float_arr), which 0.8 now rejects before the code under test runs. Adapt the tests to work across the supported spatialdata range (>=0.3) instead of pinning: - test_render_labels_rejects_float_dtype: assert the stack rejects float labels with an 'integer dtype' error at whichever layer enforces it (spatialdata's model validation on >=0.8, our render-time guard on <0.8) by moving the construction inside pytest.raises and matching the shared substring. - test_float_dtype_labels_supported: skip when the installed spatialdata rejects float labels at construction (>=0.8); the graceful-float path only applies to <0.8, where the fixture still builds. No runtime changes: spatialdata-plot already works across 0.3-0.8. The render-time and measure_obs float guards stay as defense-in-depth for float labels arriving via non-validated paths on older spatialdata.
timtreis
changed the title
…rder spatialdata 0.8's relational-query refactor (#1131) returns queried geometries in a different order, so overlapping shapes render in a different z-order (the 'c' circle now draws on top instead of behind). Annotation is unaffected - colors still map to the correct blobs (d=red, c=green, a=blue) - so this is a draw-order-only baseline update, not a behavior regression. Baseline regenerated from the py3.12-stable CI artifact (visual baselines are CI-environment-specific).
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #751 +/- ##
==========================================
- Coverage 79.59% 79.54% -0.05%
==========================================
Files 17 17
Lines 4641 4640 -1
Branches 1029 1029
==========================================
- Hits 3694 3691 -3
- Misses 598 599 +1
- Partials 349 350 +1 🚀 New features to boost your workflow:
|
spatialdata's query returns cropped geometries in a version-dependent order (0.8's relational-query refactor reorders them), which flips the draw/z-order of overlapping circles and thus the rendered image. Sort the queried element by index before rendering so the draw order - and the golden baseline - is deterministic across the supported spatialdata range (>=0.3), rather than pinning the baseline to one spatialdata version's query order.
Regenerated from CI now that the queried shapes are sorted before rendering; this baseline is deterministic across spatialdata versions (replaces the 0.8-query-order-specific image).
Member
Author
|
Blocked by scverse/spatialdata#1150 so we can remove the local |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
CI on the current
spatialdata(0.8.0) fails 4 tests:test_render_labels_rejects_float_dtype[float16/32/64]TestMeasureObs::test_float_dtype_labels_supportedRoot cause: spatialdata 0.8.0 added
_validate_labels_dtype(models.py), which rejects non-integer/non-bool label dtypes. It runs at every element-creation path —Labels2DModel.parse, theSpatialDataconstructor, and theLabelscontainer__setitem__all route throughget_model(validate=True). Both tests build their fixture viaLabels2DModel.parse(float_arr), so 0.8 raises in setup, before the code under test runs.This is purely a test-fixture issue: the library itself runs fine across the whole range (876/881 pass on 0.8; the other failure is an unrelated matplotlib baseline drift).
Approach — keep the low pin, no floor bump
spatialdata>=0.3is unchanged. The two tests are made version-agnostic:test_render_labels_rejects_float_dtype— assert the supported stack rejects float labels with an"integer dtype"error at whichever layer enforces it: spatialdata's model validation on ≥0.8, our render-time guard (render.py) on <0.8. Done by moving construction insidepytest.raisesand matching the shared substring.test_float_dtype_labels_supported— skip when the installed spatialdata rejects float labels at construction (≥0.8); the graceful-floatmeasure_obspath only applies to <0.8, where the fixture still builds.