Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On Tue, Jun 15, 2010 at 3:56 AM, daveloeffler dave.loeff...@gmail.com wrote: (I'm working on a couple of tickets but I can't remember my Sage wiki account password -- can someone with admin rights reset it for me?) As far as I know, nobody knows how to reset Sage wiki passwords. Just make a new account with a slightly different username, and write down your password somewhere. -- William On Jun 15, 10:14 am, Alex Ghitza aghi...@gmail.com wrote: On Tue, 15 Jun 2010 01:02:56 -0700 (PDT), Simon King simon.k...@nuigalway.ie wrote: On Jun 12, 2:38 pm, John Cremona john.crem...@gmail.com wrote: Is there still a wiki page for people to sign up to deal with one or more of these? Or a standard for trac ticket titles to ensure that effort is not duplicated? This would be good to have. See http://wiki.sagemath.org/doc5 for a very basic page listing what my detective skills found on trac. Since my mindreader skills are very limited, please add any modules that you are working on. It's really a pain if you get scooped ;) Best, Alex -- Alex Ghitza --http://aghitza.org/ Lecturer in Mathematics -- The University of Melbourne -- Australia -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On Fri, Jun 11, 2010 at 7:30 PM, Minh Nguyen nguyenmi...@gmail.com wrote: SNIP The Developer's Guide lacks a list of general areas against which testing should be performed and test code written. This is now ticket #9241: http://trac.sagemath.org/sage_trac/ticket/9241 -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
Hi all! On Jun 12, 2:38 pm, John Cremona john.crem...@gmail.com wrote: Is there still a wiki page for people to sign up to deal with one or more of these? Or a standard for trac ticket titles to ensure that effort is not duplicated? This would be good to have. For the record: I took care of sage.categories.homset, at #9235 (and before I did, I did a search for doc homset). Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On Tue, 15 Jun 2010 01:02:56 -0700 (PDT), Simon King simon.k...@nuigalway.ie wrote: On Jun 12, 2:38 pm, John Cremona john.crem...@gmail.com wrote: Is there still a wiki page for people to sign up to deal with one or more of these? Or a standard for trac ticket titles to ensure that effort is not duplicated? This would be good to have. See http://wiki.sagemath.org/doc5 for a very basic page listing what my detective skills found on trac. Since my mindreader skills are very limited, please add any modules that you are working on. It's really a pain if you get scooped ;) Best, Alex -- Alex Ghitza -- http://aghitza.org/ Lecturer in Mathematics -- The University of Melbourne -- Australia -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
(I'm working on a couple of tickets but I can't remember my Sage wiki account password -- can someone with admin rights reset it for me?) On Jun 15, 10:14 am, Alex Ghitza aghi...@gmail.com wrote: On Tue, 15 Jun 2010 01:02:56 -0700 (PDT), Simon King simon.k...@nuigalway.ie wrote: On Jun 12, 2:38 pm, John Cremona john.crem...@gmail.com wrote: Is there still a wiki page for people to sign up to deal with one or more of these? Or a standard for trac ticket titles to ensure that effort is not duplicated? This would be good to have. See http://wiki.sagemath.org/doc5 for a very basic page listing what my detective skills found on trac. Since my mindreader skills are very limited, please add any modules that you are working on. It's really a pain if you get scooped ;) Best, Alex -- Alex Ghitza --http://aghitza.org/ Lecturer in Mathematics -- The University of Melbourne -- Australia -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
They can go in separate files, files which, for example, are not included in the reference manual. The file sage/homology/tests.py is an example. Each function should have doctests (so the goal is still 100% coverage), but it's not a big deal to relegate lots of technical test to less visible places. Personally, I would much rather put the relevant tests locally right in the docstring and hide them from the documentation generators. Especially as TESTS blocks often test corner cases or other technicalities relevant to that specific function. +1 Sphinx can certainly handles hiding of TESTS if asked to. Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
Hi There, We don't even ensure that every statement of code gets executed at least once. Mike Hansen posted some code to use a tool to check that (a long time ago). I imagine that after doctest coverage is up to 100% function coverage that there will be a new push to then get the statement coverage up to 100%. It would be interesting even now to see how much statement coverage lagged behind function coverage. That would be very interesting indeed. I don't think it'll be too long before we have line profilers fully supported (and hence coverage tools too) for Cython as well as Python code. I'm not sure what tools there are to deal with branch coverage. +10 !!! See my message on the same thread. There are several files in sage which are never executed. Having an automatic way to check that could be a good way to find them, deprecate and remove them. As I said, I'd better remove unused code that adding doctests to it. Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
Hi Simon, On Fri, Jun 11, 2010 at 9:38 AM, Simon King simon.k...@nuigalway.ie wrote: SNIP Anyway, I am +1 to trying and getting a 90% overall doc test coverage; it is a valuable aim. IMO it is *always* worth it to write doc tests since it is very likely to uncover flaws (in particular if the person who writes the test is not the same as the one who wrote the code). And a good way to understand a piece of code is to write test cases for it. In security engineering, one would ask of a system: How can I break this system? What steps, input are needed in order to get the system to do what it was not intended to do. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On 6/11/10 4:19 AM, Minh Nguyen wrote: Hi Florent, On Fri, Jun 11, 2010 at 10:07 AM, Florent Hivert florent.hiv...@univ-rouen.fr wrote: SNIP They all looks like they should be deprecated and removed... If it's true I rather improving the doctest coverage by removing them than adding doctests... However I'd like to have the confirmation that they are indeed obsolete... We are aiming for a Sage 5.0 release. The major version number says it: don't expect backwards compatibility. So whatever functions, methods, classes, modules that are deprecated should be removed in Sage 5.0. Now it's time to take stock of deprecated stuff that are over 60 months old 60 months old?? How about 6-12 months? Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
Hi kcrisman, On Fri, Jun 11, 2010 at 11:19 AM, kcrisman kcris...@gmail.com wrote: SNIP But we do want doctests to test a fairly large number of the options, so just adding doctest coverage isn't enough. The doctests need to really test, as you say. Getting in more of the framework tests in (which I don't quite understand) will help, as would real randomization (which has been often discussed but perhaps is hard to implement?). In the absence of a dedicated quality assurance (QA) group, the Sage project needs to make do with what resources it has. The Developer's Guide lacks a list of general areas against which testing should be performed and test code written. Something like the list [1] David pointed out above. [1] http://www.sqlite.org/testing.html -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
Hi Jason, On Fri, Jun 11, 2010 at 7:30 PM, Jason Grout jason-s...@creativetrax.com wrote: SNIP 60 months old?? How about 6-12 months? It's = 6 months old. You know what I mean :-) -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
Hi Andrey, On Fri, Jun 11, 2010 at 2:47 PM, Andrey Novoseltsev novos...@gmail.com wrote: SNIP Where should such tests go? I am not sure that it is desirable to show 50 sophisticated examples for a single function in the interactive or compiled help. On the other hand, I really like when all the tests are right next to the body of the function. Is it possible to, say, have EXAMPLES and TESTS sections in the docstring and avoid showing TESTS by default? For the Sphynx documentation it would be nice to have a way to either expand this section on demand or have a link to the file with tests, in case someone really wants to see them... Here are some possibilities: * Define test functions with the name format _test_rest-of-function-name and put test code in there. This way, the test code and function won't show up in the reference manual. * Put test code in a separate module and don't include that module in the reference manual. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
Hi, Where should such tests go? I am not sure that it is desirable to show 50 sophisticated examples for a single function in the interactive or compiled help. On the other hand, I really like when all the tests are right next to the body of the function. Is it possible to, say, have EXAMPLES and TESTS sections in the docstring and avoid showing TESTS by default? For the Sphynx documentation it would be nice to have a way to either expand this section on demand or have a link to the file with tests, in case someone really wants to see them... Here are some possibilities: * Define test functions with the name format _test_rest-of-function-name and put test code in there. This way, the test code and function won't show up in the reference manual. Be careful ! Right now function named _test_* are those which are automatically launched by TestSuite and therefore should have a very specific prototype. So you probably want to pick a different name. Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On Jun 11, 2:46 am, Florent Hivert florent.hiv...@univ-rouen.fr wrote: They can go in separate files, files which, for example, are not included in the reference manual. The file sage/homology/tests.py is an example. Each function should have doctests (so the goal is still 100% coverage), but it's not a big deal to relegate lots of technical test to less visible places. Personally, I would much rather put the relevant tests locally right in the docstring and hide them from the documentation generators. Especially as TESTS blocks often test corner cases or other technicalities relevant to that specific function. +1 Sphinx can certainly handles hiding of TESTS if asked to. Florent That would be so awesome! In principle, I probably should implement it, since I really want it, but in practice it will be time consuming with my (lack of) knowledge of Sphynx and I already got quite a few other things going. But if someone implements it, I will be very-very- very happy! Andrey -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On Jun 11, 2010, at 7:57 AM, Andrey Novoseltsev wrote: On Jun 11, 2:46 am, Florent Hivert florent.hiv...@univ-rouen.fr wrote: They can go in separate files, files which, for example, are not included in the reference manual. The file sage/homology/ tests.py is an example. Each function should have doctests (so the goal is still 100% coverage), but it's not a big deal to relegate lots of technical test to less visible places. Personally, I would much rather put the relevant tests locally right in the docstring and hide them from the documentation generators. Especially as TESTS blocks often test corner cases or other technicalities relevant to that specific function. +1 Sphinx can certainly handles hiding of TESTS if asked to. Florent That would be so awesome! In principle, I probably should implement it, since I really want it, but in practice it will be time consuming with my (lack of) knowledge of Sphynx and I already got quite a few other things going. But if someone implements it, I will be very-very- very happy! That was the original goal of the TESTS block being distinct from EXAMPLES. I don't think it's a matter of if, rather when. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
Hi Andrey, They can go in separate files, files which, for example, are not included in the reference manual. The file sage/homology/tests.py is an example. Each function should have doctests (so the goal is still 100% coverage), but it's not a big deal to relegate lots of technical test to less visible places. Personally, I would much rather put the relevant tests locally right in the docstring and hide them from the documentation generators. Especially as TESTS blocks often test corner cases or other technicalities relevant to that specific function. +1 Sphinx can certainly handles hiding of TESTS if asked to. Florent That would be so awesome! In principle, I probably should implement it, since I really want it, but in practice it will be time consuming with my (lack of) knowledge of Sphynx and I already got quite a few other things going. But if someone implements it, I will be very-very- very happy! Looks like you asking me to do it ;-) I probably can do that but not before finishing the current sphinx patch #9128 before starting a new one. By the way, if any sphinx expert (Mike ???) can have help reviewing this patch, I would really appreciate. My sphinx expertise in improving, but I can't say that I'm exactly sure what I am doing there. Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
Hi David, On 11 Jun., 00:32, Dr. David Kirkby david.kir...@onetel.net wrote: At least from my very little understanding of this, Having 89% coverage would be better than 90% coverage, if those 89% were well targeted. It is not clear to me why one module should be considered being more important than another. I would not support if you suggest targeting the effort by the *topic* of the modules being doc tested. Arguing like many people do calculus and graphics, so, concentrate on this will only lead to a meta-discussion. Or do you just say that adding a single doc test to a module with 0% coverage will have a better impact than adding a single test for a module with 70% coverage? This might indeed be a good way to find a starting point. Anyway, I am +1 to trying and getting a 90% overall doc test coverage; it is a valuable aim. IMO it is *always* worth it to write doc tests since it is very likely to uncover flaws (in particular if the person who writes the test is not the same as the one who wrote the code). My 0.02€ Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On 06/11/10 12:38 AM, Simon King wrote:
Hi David,
On 11 Jun., 00:32, Dr. David Kirkbydavid.kir...@onetel.net wrote:
At least from my very little understanding of this, Having 89% coverage would be
better than 90% coverage, if those 89% were well targeted.
It is not clear to me why one module should be considered being more
important than another. I would not support if you suggest targeting
the effort by the *topic* of the modules being doc tested. Arguing
like many people do calculus and graphics, so, concentrate on this
will only lead to a meta-discussion.
I would not say there is no logic to that, but it was not what I was suggesting.
Or do you just say that adding a single doc test to a module with 0%
coverage will have a better impact than adding a single test for a
module with 70% coverage? This might indeed be a good way to find a
starting point.
That was exactly what I meant. In the case of the interface to tachyon, it would
appear there is absolutely no testing of this whatsoever
# interfaces/tachyon.py: 0% (0 of 4)
so adding just one test would be useful. It would at least show the interface is
not completely broken.
In contrast, getting graphs/generic_graph.py up to 100%, by adding one test when
there are already 200, would seem less useful to me.
# graphs/generic_graph.py: 99% (200 of 201)
So I would suggest that doctests are targeted, rather than randomly chosen. (The
obvious way to get the coverage up quickly is to write simple tests.)
Anyway, I am +1 to trying and getting a 90% overall doc test coverage;
it is a valuable aim.
Yes, but IMHO, it is a bit of a simplistic metric.
I personally do not feel Sage is sufficiently tested, and I doubt my opinion
will change if the doctest coverage is increased to 100%.
IMO it is *always* worth it to write doc tests since it is very likely
to uncover flaws (in particular if the person who writes the test is
not the same as the one who wrote the code).
Really, that should be the case.
http://www.sqlite.org/testing.html
is worth a read. Particularly section 7.1 about how there are various ways of
defining test coverage. (I stuck section 7.1 below my name). What is clear is
that the method of calculating coverage in Sage is even weaker than what that
sqlite document consider to be a weak method (statement coverage). We don't even
ensure that every statement of code gets executed at least once.
Dave
Section 7.1 from http://www.sqlite.org/testing.html
=
There are many ways to measure test coverage. The most popular metric is
statement coverage. When you hear someone say that their program as XX% test
coverage without further explanation, they usually mean statement coverage.
Statement coverage measures what percentage of lines of code are executed at
least once by the test suite.
Branch coverage is more rigorous than statement coverage. Branch coverage
measure the number of machine-code branch instructions that are evaluated at
least once on both directions.
To illustrate the difference between statement coverage and branch coverage,
consider the following hypothetical line of C code:
if( ab c!=25 ){ d++; }
Such a line of C code might generate a dozen separate machine code instructions.
If any one of those instructions is ever evaluated, then we say that the
statement has been tested. So, for example, it might be the case that the
conditional expression is always false and the d variable is never
incremented. Even so, statement coverage counts this line of code as having been
tested.
Branch coverage is more strict. With branch coverage, each test and each
subblock within the statement is considered separately. In order to achieve 100%
branch coverage in the example above, there must be at least three test cases:
* a=b
* ab c==25
* ab c!=25
Any one of the above test cases would provide 100% statement coverage but all
three are required for 100% branch coverage. Generally speaking, 100% branch
coverage implies 100% statement coverage, but the converse is not true. To
reemphasize, the TH3 test harness for SQLite provides the stronger form of test
coverage - 100% branch test coverage.
My 0.02€
Simon
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
That was exactly what I meant. In the case of the interface to tachyon, it would appear there is absolutely no testing of this whatsoever # interfaces/tachyon.py: 0% (0 of 4) Though there is some testing of it in the plot files. The point is good, just not for that example. In contrast, getting graphs/generic_graph.py up to 100%, by adding one test when there are already 200, would seem less useful to me. # graphs/generic_graph.py: 99% (200 of 201) So I would suggest that doctests are targeted, rather than randomly chosen. (The obvious way to get the coverage up quickly is to write simple tests.) But we do want doctests to test a fairly large number of the options, so just adding doctest coverage isn't enough. The doctests need to really test, as you say. Getting in more of the framework tests in (which I don't quite understand) will help, as would real randomization (which has been often discussed but perhaps is hard to implement?). Florent's point is also very good. There are a number of files which are no longer needed (e.g., axes.py) which are nearly undoctested. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On 6/10/10 7:20 PM, Dr. David Kirkby wrote: We don't even ensure that every statement of code gets executed at least once. Mike Hansen posted some code to use a tool to check that (a long time ago). I imagine that after doctest coverage is up to 100% function coverage that there will be a new push to then get the statement coverage up to 100%. It would be interesting even now to see how much statement coverage lagged behind function coverage. Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On Jun 10, 9:41 pm, Jason Grout jason-s...@creativetrax.com wrote: I imagine that after doctest coverage is up to 100% function coverage that there will be a new push to then get the statement coverage up to 100%. It would be interesting even now to see how much statement coverage lagged behind function coverage. Where should such tests go? I am not sure that it is desirable to show 50 sophisticated examples for a single function in the interactive or compiled help. On the other hand, I really like when all the tests are right next to the body of the function. Is it possible to, say, have EXAMPLES and TESTS sections in the docstring and avoid showing TESTS by default? For the Sphynx documentation it would be nice to have a way to either expand this section on demand or have a link to the file with tests, in case someone really wants to see them... Thank you, Andrey -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On Jun 10, 9:47 pm, Andrey Novoseltsev novos...@gmail.com wrote: On Jun 10, 9:41 pm, Jason Grout jason-s...@creativetrax.com wrote: I imagine that after doctest coverage is up to 100% function coverage that there will be a new push to then get the statement coverage up to 100%. It would be interesting even now to see how much statement coverage lagged behind function coverage. Where should such tests go? They can go in separate files, files which, for example, are not included in the reference manual. The file sage/homology/tests.py is an example. Each function should have doctests (so the goal is still 100% coverage), but it's not a big deal to relegate lots of technical test to less visible places. -- John -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On Jun 10, 2010, at 10:34 PM, John H Palmieri wrote: On Jun 10, 9:47 pm, Andrey Novoseltsev novos...@gmail.com wrote: On Jun 10, 9:41 pm, Jason Grout jason-s...@creativetrax.com wrote: I imagine that after doctest coverage is up to 100% function coverage that there will be a new push to then get the statement coverage up to 100%. It would be interesting even now to see how much statement coverage lagged behind function coverage. Where should such tests go? They can go in separate files, files which, for example, are not included in the reference manual. The file sage/homology/tests.py is an example. Each function should have doctests (so the goal is still 100% coverage), but it's not a big deal to relegate lots of technical test to less visible places. Personally, I would much rather put the relevant tests locally right in the docstring and hide them from the documentation generators. Especially as TESTS blocks often test corner cases or other technicalities relevant to that specific function. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: pushing towards 90% doctest coverage for Sage 5.0
On Jun 10, 2010, at 8:41 PM, Jason Grout wrote: On 6/10/10 7:20 PM, Dr. David Kirkby wrote: We don't even ensure that every statement of code gets executed at least once. Mike Hansen posted some code to use a tool to check that (a long time ago). I imagine that after doctest coverage is up to 100% function coverage that there will be a new push to then get the statement coverage up to 100%. It would be interesting even now to see how much statement coverage lagged behind function coverage. That would be very interesting indeed. I don't think it'll be too long before we have line profilers fully supported (and hence coverage tools too) for Cython as well as Python code. I'm not sure what tools there are to deal with branch coverage. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
