On Sun, Aug 18, 2019 at 5:58 AM TB <mathze...@gmail.com> wrote: > > On 13/08/2019 13:55, E. Madison Bray wrote: > > On Tue, Aug 13, 2019 at 11:28 AM Simon King <simon.k...@uni-jena.de> wrote: > >> > >> Hi, > >> > >> I am sorry for the late answer (and I am a bit surprised that nobody > >> else answered before). > >> > >> I believe it is somehow useful to have such a feature when developing a > >> large piece of new code (so that one can do a relevant subset of tests > >> quickly). However, I am not so sure how that feature would be used once > >> the piece of code is published. I.e., I cannot see how that feature > >> would be useful in the Sage test suites, but I see potential use in > >> development. > > > > It's useful to have in general, even after initial development of some > > code. For example, sometimes if just one test is failing in some > > particular case or another (i.e. a regression) it is very useful to be > > able to easily run just that test. > > > > For example, in pytest, it's possible to test not just a specific > > file, but also drill down into specific test cases, by name (including > > wildcards). > > > > With Sage's extensive use of doctests this is a little trickier but > > not impossible, and is something I've often wanted as well. > > > > One approach which would be fairly easy would be to extend the doctest > > interface to accept a line number, or even range of line numbers, on > > which to run tests. At the command line this could be a syntax like: > > > > ./sage -t <filename>:<lineno> > > > > This is imperfect of course. For example, what if you're actively > > editing the file that contains the test? Then the line number will > > move around and you'd have to keep changing it. If nothing else it > > might be able to allow some fuzz (e.g. start on the nearest doctest > > block to that line number). > > > > It can also fail if the test you're running depends on some results > > from a previous doctest block. Obviously in that case it is the > > user's responsibility to make sure that the test they want to focus on > > works in isolation (though this is also why allowing a range syntax > > like <filename>:<start>-<end> is useful). > > > > Yes, I was thinking about this feature for a faster edit-test > development loop. This should be useful also when touching existing > code, and not just when adding new code. > > Usually I have another shell to run "sage -t /some/file" while editing > that file, and in most cases this is fast enough. But when used with > --long this gets longer, of course, and testing pieces of code that are > surely irrelevant during development. > > With such a feature, it should be easy to have a key binding, in an > editor of choice, that would run just the relevant doctests. Looking at > the doctest module docs [1] there is the run_docstring_examples() > function [2] function and an unittest API section, but I do not know how > easy it will be to integrate with Sage's doctest.
I would suggest opening an issue for it. Doesn't guarantee anyone will bother to implement it, but if it's just left as a mailing list thread it's guaranteed no one will remember. -- 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/CAOTD34b%2BTxEF9iV%2Bs4Eibx5eukRegdJT_XibdeJqF-Uc0wNd1w%40mail.gmail.com.
