Am 22.02.2013 22:18, schrieb Matthew Rocklin:
This is a related issue
https://code.google.com/p/sympy/issues/detail?id=3658
It would also be great to measure the test-time of each function and each
module in aggregate. For example sympy.stats takes a fair amount of time
in testing but is relatively unused, something should probably be done
about that.
I suspect that there are a number of tests throughout SymPy that we could
mark as @slow or maybe @kindaslow to help with this. Actually, I really
like the @kindaslow idea. It would be nice to give @slow a priority
@slow(1), @slow(2) so that we could choose what level of testing we care
about. We could then run Travis on the slowest level which allows it to
not be backed up.
I've been noticing that the @slow markers sometimes don't reflect what's
slow and what isn't. That's going to get worse with the number of
categories.
I'm not sure how to deal with this.
I was thinking about reporting any discrepancies after a test run.
It would be easy to deal with different computer speeds, too.
However, I have no idea how to deal with variation in test duration.
Regards,
Jo
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
