Actually, I find it more problematic that sage -t --long may pass (which is what the patchbots check), but sage -t fails (which is what most users running the tests probably see)
Martin Am Donnerstag, 29. November 2018 10:38:54 UTC+1 schrieb E. Madison Bray: > > On Wed, Nov 28, 2018 at 12:25 PM Jeroen Demeyer <j.de...@ugent.be > <javascript:>> wrote: > > > > On 2018-11-28 09:17, E. Madison Bray wrote: > > > +1 There are several tests which, when run in an unusual order, result > > > in random failures. This is obviously a failure of test isolation if > > > nothing else, and such cases *should* be rooted out and fixed. > > > > It's not a failure of "test isolation" if nobody ever claimed that tests > > *are* isolated. The only way to really have test isolation is to run a > > separate process for each test. We already do that for separate files, > > but not for individual tests. > > But I sometimes get failures in tests depending on which order the > *files* were run in. That's what I'm talking about. You'd think that > shouldn't happen but it can: especially since some tests do things > like write to or read resources from the user's .sage directory. By > test isolation I don't just mean isolation of tests from each other, > but also from their environment (through which tests *can* become > entangled and subject to non-local interactions :) > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
