It seems to me that one of the main innovations of sage (among other CAS) was to make writing doctests really easy *and* keep them together with the code *and* make testing them *while developing* very straightforward.
True! The final of these three points would be broken *by encouraging developers to test only the parts of sage they are interested in*, even if only slightly so. This can be seen in packages that were developed for sage, but not integrated, and used mostly for a relatively specific task. An example I have in mind is the ore_algebra package. We should not encourage that. When I develop some code, thinking to merge it eventually to sage. I first run tests only in the files that I touch. Later when the code is mature, I run all the tests in sage locally (on mac). Later after I push the code to a PR, the ci run all the tests again (on ubuntu). Later when the PR is merged and a new release of sage is made, the ci run all the tests again on many platforms. I am imagining this: Suppose a number theorist developer installed sagemath-number-theory on his platform. (You are not the developer :-) He develops some code. He tests his code by running doctests in the files he touched. Later when the code is mature, he runs all the tests in sagemath-number-theory. This is the step that gets quicker. Later when the code is pushed to a PR, the ci tests the code with all the doctests of the whole sage library. -- 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/f8ae2625-bff2-411f-9070-00619a4bd593n%40googlegroups.com.