You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sage.geometry.polyhedron provides an opportunity to study use of pytest as a replacement for TestSuite (proposed in #30738) in a small self-contained codebase.
_test_ methods for Polyhedron_base were only recently introduced in tickets such as #29934.
Important design constraint:
The polyhedron objects that can be tested depend on the presence of optional packages / Python modules such as PyNormaliz.
There are over 90 calls of TestSuite in sage.geometry.polyhedron. Which of these tests should be replaced?
The polyhedron objects that can be tested depend on the presence of optional packages / Python modules such as PyNormaliz.
That's straightforward to implement using pytest's mark mechanism: https://docs.pytest.org/en/stable/example/markers.html. Question: should the tests on optional packages be automatically skipped if the optional package is not installed (mark.skipif) or do you want to have the option to include/exclude all tests depending on the optional package (e.g. add mark.pynormaliz to the test class/method and then select all tests relying on pyronmaliz with pytest -m pynormaliz or exclude them with pytest -m "not pynormaliz")? In the latter case, in which granularity (specific optional package, all optional packages)?
Question: should the tests on optional packages be automatically skipped if the optional package is not installed (mark.skipif) or do you want to have the option to include/exclude all tests depending on the optional package (e.g. add mark.pynormaliz to the test class/method and then select all tests relying on pyronmaliz with pytest -m pynormaliz or exclude them with pytest -m "not pynormaliz")?
Same as in the existing sage -t -- there's autodetection of packages/features, but the user can also pass --optional=.... to override. See sage.doctest.control (which will need adjustments also in the course of the modularization effort).
In fact, given that any feasible transition plan will necessarily have both TestSuite and pytest tests in the codebase for some time, we should probably invoke pytest either from the doctests, or from the doctesting control script.
sage.geometry.polyhedron
provides an opportunity to study use ofpytest
as a replacement forTestSuite
(proposed in #30738) in a small self-contained codebase._test_
methods forPolyhedron_base
were only recently introduced in tickets such as #29934.Important design constraint:
PyNormaliz
.CC: @tobiasdiez @nthiery @tscrim @kliem
Component: doctest framework
Issue created by migration from https://trac.sagemath.org/ticket/31104
The text was updated successfully, but these errors were encountered: