v.what.strds: migrate tests from gunittest to pytest

[Valyrian-Code]

Migrates the v.what.strds testsuite from gunittest to pytest, continuing the one-at-a-time migrations from #7635/#7675/#7780/#7893/#7894/#7896.

Same setup and cases as before: a small strds with four registered rasters of known values, three points at the same location, checking that v.what.strds creates the output map and that every point's sampled value matches the registered raster for each time slot.

Verified locally, both pass.

[Valyrian-Code]

Same CI infra issue as noted on #7780: the failing checks are hitting an HTTP 504 from Launchpad while adding the ubuntugis-unstable PPA, unrelated to this PR. Should clear with a re-run.

[ninsbl]

The rewrite with pytest looks good. That said, the test unfortunately does not really test the result correctness in a reliable way.
The raster maps contain only 1 value at a time, so one would not notice if e.g. points order gets mixed up. It would be better to create e.g. ranrom rasters or rasters where pixel values are x * y, along with a vector map with known point locations, so also pixel-shifts or point-reordering would ret noticed in the output.
That said, I have no objections merging this.

[Valyrian-Code]

Thanks for the review and for merging this as is. Good point on the raster values, using position-dependent values (like x*y) with points at known locations would catch ordering or position bugs that flat single-value rasters can't. I will keep that in mind for the next few migrations.

[ninsbl]

I will keep that in mind for the next few migrations.

Do you plan to address this in a follow up PR, if not, I guess it will get lost...

[Valyrian-Code]

Yes, I will open one once this merges, same as #7821 to #7863, so this stays a plain migration.

Plan is rasters built from row() and col() instead of flat values, and points at fixed coordinates via v.in.ascii rather than seeded v.random, so a pixel shift or a reordered point actually changes the expected value.

[Copilot]

🔵 Needs a closer look

Retain complete category-inclusive row assertions and align the fixture documentation with the generated point locations.

Pull request overview

Migrates v.what.strds tests from gunittest to pytest.

Changes:

• Adds isolated pytest coverage.
• Verifies output map creation and sampled STRDS values.
• Removes the legacy gunittest suite.

File summaries

File	Summary
scripts/v.what.strds/testsuite/test_what_strds.py	Removes migrated gunittest tests.
scripts/v.what.strds/tests/v_what_strds_test.py	Adds pytest fixtures and coverage; complete data-row assertions and fixture documentation need adjustment.

Review details

Suppressed comments (2)

scripts/v.what.strds/tests/v_what_strds_test.py:64

• This assertion drops the category column with split("|", 1), so the test would still pass if the output contained duplicate or incorrect categories. The removed gunittest test asserted the exact 1, 2, and 3 rows; retain that coverage by comparing the complete data rows.

        assert line.split("|", 1)[1] == EXPECTED_VALUES

scripts/v.what.strds/tests/v_what_strds_test.py:16

• This fixture docstring says the three points share one location, but v.random generates random point coordinates, so the setup does not match the scenario described by the test or PR. Either create coincident points explicitly if that behavior is required, or describe these as randomly placed points so the test's intent is not misleading.

    """A GRASS session with a small space time raster dataset and three
    points sharing the same location, so every point samples the same
    known values from each of the four registered rasters."""

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.