tools: implement dynamic jupyter utils tests using session_with_data

[AkshadSonawane]

Reopening and updating after feedback on #7198.

Updates in this iteration

• Refactored repeated logic from mapping classes into a centralized utils.py.
• Reworked the testing approach to use the session_with_data fixture instead of mocks or hardcoded values.
• test_get_region now dynamically validates output against the native backend (gs.region()), so it works consistently both locally and with the CI North Carolina dataset.
• Added parametrized tests for display command parsing using @pytest.mark.parametrize.
• All tests are passing cleanly against a compiled GRASS 8.6.0dev build.

Local test run

[petrasovaa]

This is an overkill for one simple function. The test file could cover all the functions in utils. You can use session_with_data and test the actual values. What is the integration mark for?

[AkshadSonawane]

This is an overkill for one simple function. The test file could cover all the functions in utils. You can use session_with_data and test the actual values. What is the integration mark for?

@petrasovaa
I've force-pushed an updated version of this PR based on your feedback.

The logic is now centralized in utils.py, and tests use the session_with_data fixture instead of hardcoded values, making them compatible with both local setups and CI.

I've also updated the PR description and included a clean test run.

Looking forward to your feedback!

[AkshadSonawane]

Hi @petrasovaa,

Working on this PR along with #7207 gave me a good understanding of both the session_with_data testing approach and the Tools API changes.

As a next step, I’m interested in applying this testing strategy to the higher-level rendering classes in grass.jupyter (like InteractiveMap and SeriesMap), which currently lack dynamic test coverage. This is also something I’m considering exploring further in my proposal.

I’m planning to prototype this for InteractiveMap. Does this sound like a useful direction?

Thanks!

[petrasovaa]

should be probably grass_jupyter_utils_test.py.

[petrasovaa]

what about if neither width or height are provided?

[AkshadSonawane]

Thanks, good point. When neither width nor height is given, the function falls back to the default bounding box limits and computes the final size from the region aspect ratio.

I updated the test to cover that case and added checks for both a wide region and a tall region, since the function handles those two sizing paths separately. I also renamed the file to grass_jupyter_utils_test.py. I ran the updated tests locally and they pass.