Hi GRASS team, and the respected mentors (@wenzeslaus, @annakrat and Stefan) of the project titled Support writing tests with pytest
I am also interested in this project for GSoC 2026. I have looked into the repository which shifted testsuite to pytest in GDAL: GitHub - craigds/gdal-pytest: Some scripts I used to do https://github.com/OSGeo/gdal/pull/963 · GitHub by craigds. I have also looked into one of the presentation given by him at PyCon “How I migrated a huge OSS project to use pytest”.
Here he explained how he used bowler to automate the refactoring, and some of the motivation for refactoring which is also explained in the grass GSoC project description.
Here are some of the things which I think is needed based on my experience of running testsuite locally:
-
as in description, there are several assert statement inside testsuite gunittest/case.py. Some of which can be replaced by simple assert first==second, for example: self.assertEqual, self.assertMultiLineEqual. Whereas some of these need special functions assertVectorFitsExtendedInfo, assertRasterFitsUnivar, etc. For these functions, we might need to create similar functions in pytest and call assert vector_fits_extended_info(…), etc
-
Although pytest is compatible with testsuite (we can run pytest to run the test in a GRASS Shell), running pytest in normal terminal will not work. This is because pytest will need a grass environment to run all the grass commands. Thus we need to make a fixture of scope=session which will set up the grass environment, allowing us to run pytest outside grass shell.
-
Since, pytest is compatible with testsuite, we can iteratively refactor the testsuite to use the new pytest functions. I will explore how to do it automatically using Bowler or other tools.
-
create and tear down temporary mapset for each test function, so that our original data is not affected by tests.
Am I missing some part of the task? Please suggest.
Thank You!
Gulshan Kumar
This is great info, Gulshan. My impression was that NumPy also went through a migration like that at some point in the past, so there might be some more lessons to learn. They even still keep some of their assert functions if I recall correctly a recent PR discussion in the OSGeo/grass repo.
- You need to plan for some design work here. How do we want the asserts to look like and how do NumPy arrays play into that? You don’t need the answers for the proposal, but you should plan for asking the questions. Check some of our tests which are using NumPy arrays with the new API.
- Yes, pytest outside of a session is a design requirement I would say.
- a) Yes for iterative. I don’t know if we should be moving migrated tests from testsuite to tests dir. b) I also don’t know if moving completely away from unittest is the way or just running unittest classes though pytest. c) Bowler looks good. I can see an AI agent as being potentially successful in this as well (or in combo with something like Bowler).
- unittest (and grass.gunittest) has its logic for setup and tear down on level of functions and classes. I assume that the pytest execution takes care of that and we should align the fixtures with that. The elephant in the room in the NC SPM sample dataset which the gunittest tests rely on and we don’t have it in pytest at all, but that may be straightforward at the end. The mapset setup and teardown is happening for every file in grass.gunittest, but the fixtures for the new pytest tests are much more “wasteful” with the mapsets and it seems to be fine (and yes, it does improve isolation tremendously), so perhaps the one-mapset-per-file approach was a premature optimization (it was also technically simpler given the session management choices at that time).
Missing: While not major part of GSoC, some type of user guide for contributors will be crucial for adoption. I already mentioned the NC SPM sample dataset.
Sorry for the wait.
Vaclav
Thank you for the suggestions.
I have added all of these points in my proposal. I have also shared my draft proposal with you via Google Drive. Please have a look and suggest any addition to it.
Meanwhile, I will look into numpy migrations and our tests which are using numpy arrays.
Thank You
Gulshan