There are ways to "bloat" the set of doctests with minimal impact. For example, we could create a file "TESTS.py" (for example) in a Sage module, consisting only of doctests. It would not be included in the reference manual, not visible when someone does "X.my_favorite_method?" or "X.my_favorite_method??", and since it's a separate file, many developers wouldn't interact with it at all. There may already be some files like that in the Sage library.
Yes. Those ways may have their own advantages. But more doctests in whatever ways will lead to more time to test sage. I don't know if this approach is worth it, but it does provide a way to add more doctests with minimal impact on most users and developers. "more time testing sage" leads to "more developer time to test PRs". I think adding doctests just to test all code paths is wasting developer time. It seems we have to choose between: (1) We keep the status quo: not testing every code path created in the PR results in the PR check failure. (2) we keep codecov/patch as it is, but require to add doctests for every code path created in the PR. (3) We keep our current practice (add doctests for major functionality, and later doctests are added for broken cases). We change codecov/path to report but not fail. I propose to take (3) . -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/69238bec-92d8-4803-b26b-51e3e64f5a22n%40googlegroups.com.
