[Valyrian-Code]

Migrates the r.random.cells testsuite from gunittest to pytest, continuing the one-at-a-time migrations from #7635/#7675/#7780.

Keeps the same three cases and the same seed=100, so the reproduced values match the original test:

• distance=0.01 fills every cell with a unique category (cells == n, no nulls)
• distance=2.00001 (just over the cell width) fills less than half the cells; the exact count depends on the random sequence, so this keeps the original's loose upper-bound check rather than pinning an exact value
• ncells=12 limits the fill to exactly that many cells

Verified locally, all three pass.

[Copilot]

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Pull request overview

Migrates r.random.cells test coverage from the legacy gunittest harness to pytest, preserving the three existing behavioral cases and seed-based expectations.

Changes:

• Removes the gunittest-based test file under testsuite/.
• Adds a new pytest test module using an isolated GRASS project/session fixture.
• Re-implements the same three assertions using r.univar JSON output.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
raster/r.random.cells/testsuite/test_random_cells.py	Removes the previous gunittest tests being migrated.
raster/r.random.cells/tests/r_random_cells_test.py	Adds pytest equivalents using grass.script + Tools and r.univar JSON assertions.

---

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

[echoix]

@wenzeslaus Is there a known pattern for gunittest "assertRasterFitsUnivar" to pytest? Otherwise, we would be recopying the assertions but we are loosing the fact that these multiple independant asserts mean something when together (so the pattern will probably diverge accross files in the future).

[Valyrian-Code]

Thanks for the review. A few notes:

• Fixture scope: kept function-scoped on purpose, isolated per test with a fresh tmp_path project. This matches the pattern in the already-merged r.cross (r.cross: migrate tests from gunittest to pytest #7635) and r.null (r.null: migrate tests from gunittest to pytest #7675) migrations, and avoids the shared-state cleanup that a module or session scope would need between tests.
• SPDX-FileCopyrightText: neither r.null nor r.cross added this to their new pytest files, only SPDX-License-Identifier, so kept it consistent with that.
• Fixture name: "session" matches the name used in r.null and r.support's already-merged tests, so kept it for consistency across the migrated files.

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

[wenzeslaus]

Is there a known pattern for gunittest "assertRasterFitsUnivar" to pytest?

No. I did not plan that either. The assert function is necessary with unittest and before grass.tools/JSON, but with grass.tools/JSON and explicit asserts in pytest, there is a less need for it.

Also, I would like to minimize test-specific functions.

Otherwise, we would be recopying the assertions but we are loosing the fact that these multiple independant asserts mean something when together...

The pattern is there, but not strong. Sometimes you want min and max, sometimes all. This can already diverge even with the assertRasterFitsUnivar. But you can continue on, sometimes you test "within range" rather than specific values. Tolerances might be different...

What is common in the r.univar call which is still there and shared.

Also, a lot of these calls, esp. elsewhere, are basically trying to test the specific result, but instead of pinning the specific values one by one, they test the overall result properties. Not the same, but close enough esp. with low tolerances.

(On that note, a follow up PR could add tiny data with specific values.)

[wenzeslaus]

This looks great. A possible follow-up would be to pin the actual locations like my recent #8077 or #8078 (no need to overdo it since it would change with seed or RNG engine, but that's exactly what such as test should catch).

[wenzeslaus]

@Valyrian-Code I changed the title because the PR or (the derived squash) commit title will be eventually used to sort out inputs to release notes. This is really only changing the tests, not the tool, so not that interesting from user perspective. Prefixing it with "tests" rather than the tool name will allow the deterministic script sort it to a developer category rather than the end-user-relevant tool category.

Here is message I used for the squash commit. You can include suggested message for the squash merge commit in the PR description (I prefer to use the details block for it now). We have the UI currently set in the way that it takes PR title for commit title/subject and for the commit body it takes commit titles/subject lines which brings up the changes done, but dedicated message is usually better at including details and filtering out minor fixes, while allowing the PR description be much more loose and rich than what the commit message can bare.

Migrates the r.random.cells testsuite from gunittest to pytest. Keeps the same three cases and the same seed=100, so the reproduced values match the original test.

The exact count in distance driven "fill some" case depends on the random sequence, so this keeps the original's loose upper-bound check rather than pinning an exact value, keeping the checks to be the theoretical bounds checks, rather than exact pins of specific results for a given seed.