On Jun 15, 2010, at 3:15 AM, William Stein wrote:
On Tue, Jun 15, 2010 at 2:09 AM, daveloeffler
<dave.loeff...@gmail.com> wrote:
On Jun 14, 11:25 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
So the doctests for that function are useless for testing that
function,
obviously.
I've wondered before if there's any way to make the test script check
that a given function has actually been called. I've seen several
errors similar to the above, with buggy code that was masked by code
in other modules, so the doctests for the original function were
actually calling something entirely different.
I doubt it in *general* due to the subtlety of Cython, which is a
massive part of Sage...
With line profiling (to be implemented, but not too hard), we can
start getting line coverage stats for our test suite, which would be
very interesting to look at. (In fact, we could get function coverage
right now, as function profiling works for both Cython and Python).
I very often write doctests that defensively avoid this. E.g., if I'm
writing a test in a class Foo,
then in my test I'll put
sage: make object X
sage: type(X)
Foo
sage: ...
This is especially important, because "make object X" could in the
future make an object of a totally different class, e.g., when
polynomials over QQ eventually switch to using FLINT. Then all tests
using them would not really be testing the generic polynomial class!
So the above means the relevant tests would break, and one would have
to replaces polys over QQ by some other generic poly class for generic
tests.
+1. I try to do this too (not for every doctests, but for enough that
things will break if I start creating/testing the wrong implementation).
- 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
