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.

Reply via email to