On Saturday, October 5, 2024 at 6:38:20 AM UTC-7 Kwankyu Lee wrote:
.... But I don't know how big a problem the codecov issue is ... We want to regard the check failure as there is a problem with the PR that the author should resolve. Currently the codecov failure triggers the check failure, but no reviewer and no author regard the codecov failure as a problem with the PR (this is the practice that you are used to) The check failure by the codecov failure is just annoying. Still, "untested is broken", right? This is still a good maxim. But our practice is "broken is then tested". I think our practice is not bad. Testing every code path would bloat our set of doctests. 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. 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. John -- 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/67c8b9ae-593f-4f43-bb4a-2cf10c241e02n%40googlegroups.com.
