The fact there are functions in Sage untested is worrying, and I think
its fair to say most people would like to see 100% doctest coverage,
but IMHO, we need a plan for this to happen, and the plan inforced,
otherwise this will not happen soon. So I'm suggesting we collect
ideas for a plan.
Two things that do NOT appear to work, at least in isolation are:
A) Saying coverage should be x % in release Y, then hoping it is.
B) Saying coverage should be x % by the date DD/MM/YY, then hoping it is.
Both of these have been tried, and niether are working. The graph here
seems to indicate that progress on this has slowed over the last year
or so, where progress was about 4.7% per year. (I'm not actually sure
I agree with his line of best fit, which would suggest to me the
situation has slowed even more.)
A few ideas that might work, are below. I would add, I'm not
suggesting they are all very good (in particular 1 and 4 are a bit
excessive), but I mention them anyway.
1) Having a release, where the only aim is to increase doctest
coverage. No patches are accepted, unless they increase coverage.
2) Finding sections of code which are not tested, and depreciating
them, unless someone writes the doctests, in which case the
depreciation can be removed.
3) Having a release, where anyone can submit a patch which gets
reviewed, but the release manager does not merge it unless the author
of the patch can provide another patch which increase doctest
coverage.
4) Finding individuals that have written code that is not tested, and
not merging any more patches from them unless they first add tests to
the ALL code they have already written.
5) Finding individuals that have written code that is not tested, and
not merging any more patches from them unless they first add tests to
a number (say 5) tests for all the code they have written which is
untested.
6) Not accepting any patches, unless a equal number of lines of code
are submitted which add doctests.
7) Paying individuals to just write tests.
I believe if we want to achieve 100% coverage, we need to do more than
A and B above, as they are proved not to work.
Can anyone suggest anything else, or have any comments.
On 29 April 2012 15:35, David Kirkby <david.kir...@onetel.net> wrote:
> A few ideas that might work, are below. I would add, I'm not
> suggesting they are all very good (in particular 1 and 4 are a bit
> excessive), but I mention them anyway.
Sorry, it was 2 and 4 which I feel are going too far.
This is going ta bit too far, but I mention it for completeness.
> 2) Finding sections of code which are not tested, and depreciating
> them, unless someone writes the doctests, in which case the
> depreciation can be removed.
Same with this.
> 4) Finding individuals that have written code that is not tested, and
> not merging any more patches from them unless they first add tests to
> the ALL code they have already written.
But I feel the other 5 have some merrit, and all are at least worth of
discussion.
On Sunday, April 29, 2012, David Kirkby wrote:
> On 29 April 2012 15:35, David Kirkby <david.kir...@onetel.net<javascript:;>>
> wrote:
> > A few ideas that might work, are below. I would add, I'm not
> > suggesting they are all very good (in particular 1 and 4 are a bit
> > excessive), but I mention them anyway.
> Sorry, it was 2 and 4 which I feel are going too far.
> This is going ta bit too far, but I mention it for completeness.
> > 2) Finding sections of code which are not tested, and depreciating
> > them, unless someone writes the doctests, in which case the
> > depreciation can be removed.
> Same with this.
> > 4) Finding individuals that have written code that is not tested, and
> > not merging any more patches from them unless they first add tests to
> > the ALL code they have already written
I would be banned for life!
> But I feel the other 5 have some merrit, and all are at least worth of
> discussion.
> Dave
> --
> To post to this group, send an email to sage-devel@googlegroups.com<javascript:;>
> To unsubscribe from this group, send an email to
> sage-devel+unsubscribe@googlegroups.com <javascript:;>
> 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
On 29 April 2012 16:10, William Stein <wst...@gmail.com> wrote:
> On Sunday, April 29, 2012, David Kirkby wrote:
>> > 4) Finding individuals that have written code that is not tested, and
>> > not merging any more patches from them unless they first add tests to
>> > the ALL code they have already written
> I would be banned for life!
Perhaps you would agree to the number 5 I suggested earlier.
5) Finding individuals that have written code that is not tested, and
not merging any more patches from them unless they first add tests to
a number (say 5) tests for all the code they have written which is
untested.
I feel #5 is more likely to lead to a 100% doctested Sage than setting
arbitrary percentages by arbitrary dates or arbitrary version numbers.
On Sunday, April 29, 2012, David Kirkby wrote:
> On 29 April 2012 16:10, William Stein <wst...@gmail.com <javascript:;>>
> wrote:
> > On Sunday, April 29, 2012, David Kirkby wrote:
> >> > 4) Finding individuals that have written code that is not tested, and
> >> > not merging any more patches from them unless they first add tests to
> >> > the ALL code they have already written
> > I would be banned for life!
> Perhaps you would agree to the number 5 I suggested earlier.
> 5) Finding individuals that have written code that is not tested, and
> not merging any more patches from them unless they first add tests to
> a number (say 5) tests for all the code they have written which is
> untested.
I am opposed to anything that restricts an author from including good new
up to snuff code in Sage based on any properties ir behaviour of said
author.
> I feel #5 is more likely to lead to a 100% doctested Sage than setting
> arbitrary percentages by arbitrary dates or arbitrary version numbers.
> Dave
> --
> To post to this group, send an email to sage-devel@googlegroups.com<javascript:;>
> To unsubscribe from this group, send an email to
> sage-devel+unsubscribe@googlegroups.com <javascript:;>
> 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
> The fact there are functions in Sage untested is worrying, and I think
> its fair to say most people would like to see 100% doctest coverage,
> but IMHO, we need a plan for this to happen, and the plan inforced,
> otherwise this will not happen soon. So I'm suggesting we collect
> ideas for a plan.
As a humble user, I would like to mention something that could increase the chance of me contributing something. Perhaps it would just increase the change from 0.5% to 5%, but if many users think like me, that might still be worthwhile.
My assumption is that it is relatively easy to write a doctest.
It may very well be a bad idea, as it may be a bad user experience for people expecting a professional-looking and polished math-suite. If so, feel free to ignore it.
I use a sage 5 beta, and if I would run some code and get a message like the following:
"This function you just used lacks doctests. Contributing doctests would be a simple way for you to help improving the quality of sage. If you have an hour [I do not know what is reasonable for a first doctest submission] to spare, please have a look at the page [link here] and consider writing a test for this function."
I expect this might be a performance problem, as a lot of functions may have to be tested for the presence of doctests on every invocation.
Again, feel free to tell me why it is a bad idea, and then ignore it.
(My only, very small, contribution to sage, was prompted by a confusing (to me) part of the sage documentation, and I do believe that I would need to be pointed to simple problems in parts of sage that I use, and lack of doctests might be such a simple thing.)
On Apr 29, 7:35 am, David Kirkby <david.kir...@onetel.net> wrote:
> The fact there are functions in Sage untested is worrying,
Indeed, it would be nice if all code in Sage would be covered by
tests. Having doctests for very many functions probably correlates
with that, so it probably helps to aim for it. However, doctests don't
*perfectly* correlate with covering all code. As an example (from
ecl.pyx):
This routine does have a doctest (and counts in the general tally),
but as you see, there is very little to test about this particular
routine and in fact the correct functioning of __repr__ will be
implicitly tested by many of the other doctests in that file.
On the other hand,
cdef void remove_node(cl_object node):
cdef cl_object next, prev
next=cl_cadr(node)
prev=cl_cddr(node)
if next != Cnil:
cl_rplacd(cl_cdr(next),prev)
if prev != Cnil:
cl_rplaca(cl_cdr(prev),next)
does not have a doctest (because it cannot be tested directly from
sage) and does not count for the tally (because it's a cdef). It has a
much worse potential for messing up sage's state, but the doctest
count does not measure whether it's tested. I happen to know it is
tested elsewhere, but the greatest worry -- silent memory corruption
or memory leaks -- is not explicitly covered by those tests.
Don't get hung up on the doctest count. It's a mildly relevant
statistic.
On Sun, Apr 29, 2012 at 1:24 PM, Nils Bruin <nbr...@sfu.ca> wrote:
> On Apr 29, 7:35 am, David Kirkby <david.kir...@onetel.net> wrote:
>> The fact there are functions in Sage untested is worrying,
> Indeed, it would be nice if all code in Sage would be covered by
> tests. Having doctests for very many functions probably correlates
> with that, so it probably helps to aim for it. However, doctests don't
> *perfectly* correlate with covering all code. As an example (from
> ecl.pyx):
> This routine does have a doctest (and counts in the general tally),
> but as you see, there is very little to test about this particular
> routine and in fact the correct functioning of __repr__ will be
> implicitly tested by many of the other doctests in that file.
> On the other hand,
> cdef void remove_node(cl_object node):
> cdef cl_object next, prev
> next=cl_cadr(node)
> prev=cl_cddr(node)
> if next != Cnil:
> cl_rplacd(cl_cdr(next),prev)
> if prev != Cnil:
> cl_rplaca(cl_cdr(prev),next)
> does not have a doctest (because it cannot be tested directly from
> sage) and does not count for the tally (because it's a cdef). It has a
> much worse potential for messing up sage's state, but the doctest
> count does not measure whether it's tested. I happen to know it is
> tested elsewhere, but the greatest worry -- silent memory corruption
> or memory leaks -- is not explicitly covered by those tests.
> Don't get hung up on the doctest count. It's a mildly relevant
> statistic.
+1
-- William Stein
Professor of Mathematics
University of Washington
http://wstein.org
On 2012-04-29, Johan Grönqvist <johan.gronqv...@gmail.com> wrote:
> My assumption is that it is relatively easy to write a doctest.
> It may very well be a bad idea, as it may be a bad user experience for > people expecting a professional-looking and polished math-suite. If so, > feel free to ignore it.
> I use a sage 5 beta, and if I would run some code and get a message like > the following:
> "This function you just used lacks doctests. Contributing doctests would > be a simple way for you to help improving the quality of sage. If you > have an hour [I do not know what is reasonable for a first doctest > submission] to spare, please have a look at the page [link here] and > consider writing a test for this function."
Writing doc tests is certainly a good way to start contributing to Sage!
> I expect this might be a performance problem, as a lot of functions may > have to be tested for the presence of doctests on every invocation.
Technically, it would probably be possible to make Python print a
message whenever a function is called that is not tested. But that would
mean a HUGE performance regression, and it would be rather annoying:
Just think of a function that calls an undocumented function in a loop.
However, a variant of your idea might be feasible: When reading the
documentation of an object or when inspecting the sources, such as
sage: ZZ?
or
sage: ZZ??
some functions from sage.misc.sageinspect are called that pre-process
the documentation. Hence, it would be possible to *additionally* make
them test whether there is a doc test - and add a message to the docs
if this is not the case.
Example: Suppose you have a function
def foobar(x,y):
"""
This function does useful stuff.
"""
return x+y
and then do
sage: foobar?
it would be doable that one reads:
Type: function
Base Class: <type 'function'>
String Form: <function foobar at 0x4eb9f50>
Namespace: Interactive
Loaded File: ...
Source File: ...
Definition: foobar(x, y)
Docstring:
Please contribute to Sage by writing a doctest
for this function!
This function does useful stuff.
Here, there is no regression (reading documentation is not
time-critical), and it is clearly doable.
What do people think? Would that kind of message encourage people to do
their first contribution, or would that scare people off?
> sage: foobar?
> it would be doable that one reads:
> Type: function
> Base Class: <type 'function'>
> String Form: <function foobar at 0x4eb9f50>
> Namespace: Interactive
> Loaded File: ...
> Source File: ...
> Definition: foobar(x, y)
> Docstring:
> Please contribute to Sage by writing a doctest
> for this function!
> This function does useful stuff.
> Here, there is no regression (reading documentation is not
> time-critical), and it is clearly doable.
> What do people think? Would that kind of message encourage people to do
> their first contribution, or would that scare people off?
I think it might get people to contribute. It needs a link to a page
describing in detail the process of writing a doctest for Sage, and
how to get that doctest into Sage.
Perhaps it woud scare a few people off, but overall I would have
thought the result positive.
> Best regards,
> Simon
Currently there seems to be no plan in place to get Sage doctested.
William has rejected the idea of getting people to write 5 doctests
for previous code they have written, before a patch of theirs gets
merged. So the suggestion here might go some way to solving the
problem, though I personally think it needs a more drastic approach.
But this is certainly a step in the right direction.
On 29 April 2012 18:00, William Stein <wst...@gmail.com> wrote:
> On Sunday, April 29, 2012, David Kirkby wrote:
>> Perhaps you would agree to the number 5 I suggested earlier.
>> 5) Finding individuals that have written code that is not tested, and
>> not merging any more patches from them unless they first add tests to
>> a number (say 5) tests for all the code they have written which is
>> untested.
> I am opposed to anything that restricts an author from including good new up
> to snuff code in Sage based on any properties ir behaviour of said author.
Would you be opposed to insisting someone write one doctest for
previous code they have written, for every new patch they want merged?
I originally said 5, but would you find 1 acceptable?
On Sunday, April 29, 2012, David Kirkby wrote:
> On 29 April 2012 18:00, William Stein <wst...@gmail.com <javascript:;>>
> wrote:
> > On Sunday, April 29, 2012, David Kirkby wrote:
> >> Perhaps you would agree to the number 5 I suggested earlier.
> >> 5) Finding individuals that have written code that is not tested, and
> >> not merging any more patches from them unless they first add tests to
> >> a number (say 5) tests for all the code they have written which is
> >> untested.
> > I am opposed to anything that restricts an author from including good
> new up
> > to snuff code in Sage based on any properties ir behaviour of said
> author.
> Would you be opposed to insisting someone write one doctest for
> previous code they have written, for every new patch they want merged?
I am opposed. Moreover all code that has gone into sage for the last
about 4 years has already had 100% coverage (or a major error was made when
refereeing); since there have been many (most?) new developers since then,
this proposal would have little impact.
> I originally said 5, but would you find 1 acceptable?
> Dave
> --
> To post to this group, send an email to sage-devel@googlegroups.com<javascript:;>
> To unsubscribe from this group, send an email to
> sage-devel+unsubscribe@googlegroups.com <javascript:;>
> 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
On Sun, Apr 29, 2012 at 9:35 AM, David Kirkby <david.kir...@onetel.net> wrote:
> The fact there are functions in Sage untested is worrying, and I think
> its fair to say most people would like to see 100% doctest coverage,
> but IMHO, we need a plan for this to happen, and the plan inforced,
> otherwise this will not happen soon. So I'm suggesting we collect
> ideas for a plan.
> Two things that do NOT appear to work, at least in isolation are:
> A) Saying coverage should be x % in release Y, then hoping it is.
> B) Saying coverage should be x % by the date DD/MM/YY, then hoping it is.
> Both of these have been tried, and niether are working. The graph here
> seems to indicate that progress on this has slowed over the last year
> or so, where progress was about 4.7% per year. (I'm not actually sure
> I agree with his line of best fit, which would suggest to me the
> situation has slowed even more.)
> A few ideas that might work, are below. I would add, I'm not
> suggesting they are all very good (in particular 1 and 4 are a bit
> excessive), but I mention them anyway.
> 1) Having a release, where the only aim is to increase doctest
> coverage. No patches are accepted, unless they increase coverage.
> 2) Finding sections of code which are not tested, and depreciating
> them, unless someone writes the doctests, in which case the
> depreciation can be removed.
> 3) Having a release, where anyone can submit a patch which gets
> reviewed, but the release manager does not merge it unless the author
> of the patch can provide another patch which increase doctest
> coverage.
> 4) Finding individuals that have written code that is not tested, and
> not merging any more patches from them unless they first add tests to
> the ALL code they have already written.
> 5) Finding individuals that have written code that is not tested, and
> not merging any more patches from them unless they first add tests to
> a number (say 5) tests for all the code they have written which is
> untested.
> 6) Not accepting any patches, unless a equal number of lines of code
> are submitted which add doctests.
> 7) Paying individuals to just write tests.
> I believe if we want to achieve 100% coverage, we need to do more than
> A and B above, as they are proved not to work.
> Can anyone suggest anything else, or have any comments.
> 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+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org
Option 1) seems like a good idea to me. The others might also work,
but would surely require a lot of extra work on the part the release
manager or whoever ends up having to enforce / implement the
restrictions. That extra work would be better funneled into increasing
doctest coverage in my opinion.
We might consider combining option 1 and plan A, as you put it, but
set a realistic target %.
> On Sun, Apr 29, 2012 at 9:35 AM, David Kirkby <david.kir...@onetel.net> wrote:
>> The fact there are functions in Sage untested is worrying, and I think
>> its fair to say most people would like to see 100% doctest coverage,
>> but IMHO, we need a plan for this to happen, and the plan inforced,
>> otherwise this will not happen soon. So I'm suggesting we collect
>> ideas for a plan.
>> Two things that do NOT appear to work, at least in isolation are:
>> A) Saying coverage should be x % in release Y, then hoping it is.
>> B) Saying coverage should be x % by the date DD/MM/YY, then hoping it is.
>> Both of these have been tried, and niether are working. The graph here
>> seems to indicate that progress on this has slowed over the last year
>> or so, where progress was about 4.7% per year. (I'm not actually sure
>> I agree with his line of best fit, which would suggest to me the
>> situation has slowed even more.)
>> A few ideas that might work, are below. I would add, I'm not
>> suggesting they are all very good (in particular 1 and 4 are a bit
>> excessive), but I mention them anyway.
>> 1) Having a release, where the only aim is to increase doctest
>> coverage. No patches are accepted, unless they increase coverage.
>> 2) Finding sections of code which are not tested, and depreciating
>> them, unless someone writes the doctests, in which case the
>> depreciation can be removed.
>> 3) Having a release, where anyone can submit a patch which gets
>> reviewed, but the release manager does not merge it unless the author
>> of the patch can provide another patch which increase doctest
>> coverage.
>> 4) Finding individuals that have written code that is not tested, and
>> not merging any more patches from them unless they first add tests to
>> the ALL code they have already written.
>> 5) Finding individuals that have written code that is not tested, and
>> not merging any more patches from them unless they first add tests to
>> a number (say 5) tests for all the code they have written which is
>> untested.
>> 6) Not accepting any patches, unless a equal number of lines of code
>> are submitted which add doctests.
>> 7) Paying individuals to just write tests.
>> I believe if we want to achieve 100% coverage, we need to do more than
>> A and B above, as they are proved not to work.
>> Can anyone suggest anything else, or have any comments.
>> Dave
> Option 1) seems like a good idea to me. The others might also work,
> but would surely require a lot of extra work on the part the release
> manager or whoever ends up having to enforce / implement the
> restrictions. That extra work would be better funneled into increasing
> doctest coverage in my opinion.
> We might consider combining option 1 and plan A, as you put it, but
> set a realistic target %.
> --
> Benjamin Jones
Thank you Benjamin. Both ideas of yours seem good to me, but I don't
think they will work. William has said
==========
"I am opposed to anything that restricts an author from including good
new up to snuff code in Sage based on any properties ir behaviour of
said author."
==========
I can't see a way forward in this case. I guess we will asymptotically
approach 100%, if all new code is tested!
Personally, I would have thought it a "selling point" if we could say
"Every function in Sage is tested on numerous platforms on every
release", but alas I don't think that will happen.
On 29 Apr., 21:58, Simon King <simon.k...@uni-jena.de> wrote:
> However, a variant of your idea might be feasible: When reading the
> documentation of an object or when inspecting the sources, such as
> sage: ZZ?
> or
> sage: ZZ??
> some functions from sage.misc.sageinspect are called that pre-process
> the documentation. Hence, it would be possible to *additionally* make
> them test whether there is a doc test - and add a message to the docs
> if this is not the case.
The problem is that apparently the notebook and the command line
interface of Sage use different ways for getting the docs: There seems
to be
SAGE_ROOT/devel/sagenb/sagenb/misc/sageinspect.py and
SAGE_ROOT/devel/sagenb/sagenb/misc/support.py
for the notebook, and
SAGE_ROOT/devel/sage/sage/misc/sageinspect.py and
SAGE_ROOT/devel/sage/sage/misc/sagedoc.py
on the other hand.
What an awkward and difficult to maintain duplication of code!
Cheers,
Simon
FWIW: I created trac ticket #12891 (http://trac.sagemath.org/sage_trac/ ticket/12891), if someone likes the idea to invite users to contribute
when reading the docs of an undocumented function or method.
> FWIW: I created trac ticket #12891 (http://trac.sagemath.org/sage_trac/ > ticket/12891), if someone likes the idea to invite users to contribute
> when reading the docs of an undocumented function or method.
> Cheers,
> Simon
Is there an easy way to find a list of undocumented functions? Whilst I'm not a mathematician, I might be able to write doctests for some of them. I think William, since he started the project, has probably contributed a fair number of undocumented functions. Since they were present at the start of Sage, I assume that mathematically they are not so advanced as some of the later material.
<david.kir...@onetel.net> wrote:
> On 04/30/12 04:47 PM, Simon King wrote:
>> FWIW: I created trac ticket #12891 (http://trac.sagemath.org/sage_trac/ >> ticket/12891), if someone likes the idea to invite users to contribute
>> when reading the docs of an undocumented function or method.
>> Cheers,
>> Simon
> Is there an easy way to find a list of undocumented functions?
sage -coverage
For example,
cd SAGE_ROOT/devel/sage/sage/coding
sage -coverage .
Outputs:
ag_code.py: 100% (1 of 1)
binary_code.pyx: 91% (41 of 45)
code_bounds.py: 100% (17 of 17)
code_constructions.py: 96% (25 of 26)
decoder.py: 100% (3 of 3)
guava.py: 100% (3 of 3)
linear_code.py: 82% (52 of 63)
sd_codes.py: 20% (1 of 5)
source_coding/huffman.py: 100% (9 of 9)
Overall weighted coverage score: 88.1%
Total number of functions: 172
We need 3 more function to get to 90% coverage.
We need 11 more function to get to 95% coverage.
We need 18 more function to get to 99% coverage.
---
You can then do the following to see what is wrong with a given file:
sage -coverage sd_codes.py
----------------------------------------------------------------------
sd_codes.py
SCORE sd_codes.py: 20% (1 of 5)
> Whilst I'm
> not a mathematician, I might be able to write doctests for some of them. I
> think William, since he started the project, has probably contributed a fair
> number of undocumented functions. Since they were present at the start of
> Sage, I assume that mathematically they are not so advanced as some of the
> later material.
> 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+unsubscribe@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
If you said "We want to assure that each command (or each software "unit") has at least 1 test" and asked for enforcement proposals, maybe this makes a little bit of sense. "100% coverage" is not what I'd call it.
Having people who wrote the code be the only person who tests it is not a great idea. Neither is having people who know nothing much at all about the code write a test.
> If you said "We want to assure that each command (or each software "unit")
> has at least 1 test" and
> asked for enforcement proposals, maybe this makes a little bit of sense.
> "100% coverage" is not what I'd call it.
What would you call it?
> Having people who wrote the code be the only person who tests it is not a
> great idea.
> Neither is having people who know nothing much at all about the code write
> a test.
> Does UW have a software engineering course??
Nope.
> RJF
> --
> To post to this group, send an email to sage-devel@googlegroups.com<javascript:_e({}, 'cvml', 'sage-devel@googlegroups.com');>
> To unsubscribe from this group, send an email to
> sage-devel+unsubscribe@googlegroups.com <javascript:_e({}, 'cvml',
> 'sage-devel%2Bunsubscribe@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
On 1 May 2012 01:04, rjf <fate...@gmail.com> wrote:
> If you said "We want to assure that each command (or each software "unit")
> has at least 1 test" and
> asked for enforcement proposals, maybe this makes a little bit of sense.
> "100% coverage" is not what I'd call it.
It's not 100% branch coverage, or any of the other metrics which can
be used. There are several definitions of "coverage", but then I guess
you know that.
> Having people who wrote the code be the only person who tests it is not a
> great idea.
Agreed, but it is probably better than no testing at all, which is
what is happening with 100's of functions.
> Neither is having people who know nothing much at all about the code write a
> test.
Agreed, but once again, it is better than nothing.
> Does UW have a software engineering course??
I don't know, but I have in the past suggested William read a book on
software engineering, and even suggested he buy a copy each for the
main developers. I have personally bought a couple of books on the
subject.
I've spent a lot of time porting Sage to Solaris, but I'm reluctant to
use the program professionally, due to what I personally perceive as a
lack of testing. So I still use Mathematica, and will probably
continue to do so.
In theory, being open-source, I can check the code of Sage, but in
practice it's not practical, so the open-source nature is not much
benefit to me, apart from the cost.
On Mon, Apr 30, 2012 at 17:51, William Stein <wst...@gmail.com> wrote:
> On Monday, April 30, 2012, rjf wrote:
>> If you said "We want to assure that each command (or each software "unit")
>> has at least 1 test" and
>> asked for enforcement proposals, maybe this makes a little bit of sense.
>> "100% coverage" is not what I'd call it.
> What would you call it?
>> Having people who wrote the code be the only person who tests it is not a
>> great idea.
>> Neither is having people who know nothing much at all about the code write
>> a test.
>> --
>> To post to this group, send an email to sage-devel@googlegroups.com
>> To unsubscribe from this group, send an email to
>> sage-devel+unsubscribe@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+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org
On 1 May 2012 01:51, William Stein <wst...@gmail.com> wrote:
> On Monday, April 30, 2012, rjf wrote:
>> If you said "We want to assure that each command (or each software "unit")
>> has at least 1 test" and
>> asked for enforcement proposals, maybe this makes a little bit of sense.
>> "100% coverage" is not what I'd call it.
> What would you call it?
It is one defintion, but there are many others too, which deman more,
such as that every branch is covered, or every line of code gets
executed. That does not happen with a doc test - at least in general -
it might happen for the odd test.
>> Does UW have a software engineering course??
> Nope.
I'm surprised, but you do have a "Programming Languages and Software
Engineering Group"
> On Mon, Apr 30, 2012 at 17:51, William Stein <wst...@gmail.com> wrote:
>> On Monday, April 30, 2012, rjf wrote:
>>> If you said "We want to assure that each command (or each software "unit")
>>> has at least 1 test" and
>>> asked for enforcement proposals, maybe this makes a little bit of sense.
>>> "100% coverage" is not what I'd call it.
>> What would you call it?
>>> Having people who wrote the code be the only person who tests it is not a
>>> great idea.
>>> Neither is having people who know nothing much at all about the code write
>>> a test.
>>> --
>>> To post to this group, send an email to sage-devel@googlegroups.com
>>> To unsubscribe from this group, send an email to
>>> sage-devel+unsubscribe@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+unsubscribe@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/sage-devel >> URL: http://www.sagemath.org
> --
> Andrew
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+unsubscribe@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
David Kirkby <david.kir...@onetel.net> writes:
> I don't know, but I have in the past suggested William read a book on
> software engineering, and even suggested he buy a copy each for the
> main developers. I have personally bought a couple of books on the
> subject.
