[Valyrian-Code]

Migrates the r.fill.stats testsuite from gunittest to pytest, keeping the ASCII files and comparing arrays from Tools rather than a difference raster.

One cell changed in each reference file. The northeast corner was null but the tool fills it, in all four modes, and it is the only cell that differs. See #8057 for why the old check missed it.

Suggested squash commit message

tests: Migrate r.fill.stats from gunittest to pytest

Keeps the ASCII input and reference files and compares the tool output against the reference as NumPy arrays from Tools, rather than through a difference raster.

Corrects one cell in each of the four reference files. The northeast corner was stored as null but the tool fills it in every mode. The old assertRastersNoDifference could not detect this, since a difference against a null is itself null. Reported in #8057.

[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.

[Copilot]

Copilot review overview

🟡 Changes recommended

The NumPy comparison retains a relative tolerance, weakening the previous absolute 1e-6 assertion.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Set rtol=0 to preserve the previous absolute tolerance · New

What changed in this PR

Migrates r.fill.stats regression coverage from gunittest to pytest, using isolated GRASS sessions, grass.tools, and NumPy comparisons.

Changes:

• Adds parametrized tests for all four interpolation modes.
• Inlines input and reference raster data.
• Removes the legacy gunittest test and data files.

File	Description
raster/​r.fill.stats/​tests/​r_fill_stats_test.py	New pytest-based regression tests and inline fixtures.
raster/​r.fill.stats/​testsuite/​test_r_fill_stats.py	Removes the legacy gunittest test.
raster/​r.fill.stats/​testsuite/​data/​input_ascii.txt	Removes migrated input data.
raster/​r.fill.stats/​testsuite/​data/​output_wmean.txt	Removes migrated weighted-mean reference.
raster/​r.fill.stats/​testsuite/​data/​output_mean.txt	Removes migrated mean reference.
raster/​r.fill.stats/​testsuite/​data/​output_median.txt	Removes migrated median reference.
raster/​r.fill.stats/​testsuite/​data/​output_mode.txt	Removes migrated mode reference.

---

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

[Valyrian-Code]

Good catch, fixed. The original was an absolute precision=1e-6, and the default rtol=1e-5 let a cell near 5 drift about 5e-5, so this had quietly loosened it. Set rtol=0, all four modes still pass.

[Valyrian-Code]

The red macOS check is unrelated to this PR. All four r.fill.stats tests passed there; what failed is every test in python/grass/temporal/tests/grass_temporal_gui_support_test.py, each with Timeout (>300.0s) from pytest-timeout. macOS is green on main and on my other open PRs, so it looks like a hang on that runner rather than anything here.

[echoix]

The thing I don't like here, is that I'm not 100% sure that now or in the future, we will still test the compatibility of previous files the same way. I remember doing something to keep testsuite/data directories with the same line endings and encoding. The goal is that Windows GRASS will be able to open a file output from Linux GRASS and vice versa, and keep being able to open a previously created file in a future version.

Having the string inlined in tests, doesn't assure us that python won't be adjusting for the correct representation for that platform, so windows is testing something different than Linux.

Are you able to see if you can keep such independent data files with pytest? And maybe do the move without involving copying and pasting the contents, to keep the actual encoding? Also check with .gitattributes and editor config nothing will be lost while moving from directories.

[Valyrian-Code]

Yes, data files work with pytest. temporal/t.rast.import/tests/data already does it via pathlib.Path(__file__).parent / "data", and that one is a tar.bzip2, so bytes survive fine.

Moved the five fixtures to tests/data and went back to passing paths to r.in.ascii like the gunittest version did, so the tool reads them off disk instead of a Python literal. Took them from the stored blobs rather than copying text, and git reports all five as R100 against main.

No .gitattributes exists, and .editorconfig sets end_of_line = lf for [*] with editorconfig-checker in pre-commit. None of the five contain CR, so nothing is lost by the move. Your point stands though, inlining was the wrong shape for fixtures meant to be read as stored.

[wenzeslaus]

While I think is acceptable with the minor fixes specified in the comments, clearly showing this is a migration of the test, I think changing the reference data to the current data makes sense and would simplify the test.

As for the files, since the original input and reference is ASCII files, we can keep them here and it will make the change of the reference clearly visible. However, if this would be written from scratch today, we would likely have a NumPy array as a literal in the code skipping all conversions for the reference data. Given we want an example of having data in files for tests and the value of keeping the tests same here, let's keep it using the files here, but let's not make it a rule.

[Valyrian-Code]

Updated the reference data.
One cell per file, the northeast corner, which the tool fills and the reference had as null.

#8057 still covers the null-vs-value case that hid it.

[Valyrian-Code]

Updated the reference data. One cell per file, the northeast corner, which the tool fills and the reference had as null. #8057 still covers the null-vs-value case that hid it.