I don't know if py.test prints the mark (i.e. slow) but there are many extensions so it may be possible. The other option would be to do separate runs
py.test sympy -m 'not slow' --duration 7000 py.test sympy -m slow --duration 100 Note that the results I posted in the OP is cut/paste from the output of py.test with test names/times sorted in descending order. On Sat, Sep 27, 2014 at 12:27 AM, Joachim Durchholz <j...@durchholz.org> wrote: > Just my thinking. > > Am 26.09.2014 um 22:23 schrieb Peter Brady: > >> One of the reasons for the poor maintenance of the @slow label is (IMO) >> the >> lack of hard data. >> > > That, any - whatever anybody is doing - updating @slow decorations is > almost always unrelated. > > > The native test suite via bin/test does not support > >> timing. This is supported with py.test but the compatibility is still a >> bit sketchy. >> > > The central part of bin/test, the actual test runner, has too much > redundant code and is a bit too convoluted (or too little documented) to > make improving the whole thing easy. I once tried to refactor that piece of > code, but it proved to be far beyond what I was willing to spend in terms > of time and effort, so I dropped it. > > I'd very much like it if test.py compatibility became so good that we can > actually switch back from bin/test to test.py. > > > If we can get full py.test compatibility it will be > >> substantially easier to monitor which tests should be @slow (or skipped >> altogether) as one could get timing data with something simple like >> `py.test sympy --durations 100` >> > > I think it would be good to make it easier to write a set of fixes to > @slow decorations, and (for the merge) verify that they're really an > improvement. > For that, my idea is to have a maintenance script that runs the tests with > a timeout, times them, and spits out a report that gives, for each test: > - The test's name, > - whether it's decorated with @slow, > - its running time, > sorted by running time in descending order. > Does test.py support that? (bin/test does not - it could be hacked into > it, but that would require adding more redundant code, so it would become a > bit less maintainable.) > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sympy" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/sympy/xDM4NHWP9cA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/sympy/542658EC.7090606%40durchholz.org. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CALoNiQfdk80XgBXCeOJ7tBBppD7qtpG9BVqCAgHiGfadYB9HQQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
