>
> because I think the number of tests inside a PR is small enough that you
> probably do not see isolation failures, but you really want to see progress
> in a PR without random failures due to isolation.
>
I think it's the opposite - most isolation problems are best detected at
the time they're
Thank you for diving into how unittest discovery tests!
On Friday, March 12, 2021 at 12:14:05 PM UTC+1 chris.j...@gmail.com wrote:
> But, regardless of the default, to get the full benefit I think you'd want
> at least one of the test runs in CI to be a random one.
>
This is were I somewhat dis
On Friday, March 12, 2021 at 10:47:56 AM UTC+1 Florian Apolloner wrote:
> Is the current order defined in any way -- if not one should consider it
> randoms anyways and as such actually randomizing should not make much of a
> difference. FWIW I am fine with making it the default and outputting the
Btw while I am fine with making it default (I really do not care much
either way), we certainly need a way to disable it and keep the current
algorithm (even though it might not be guaranteed stable). When I develop I
often run one suite and fix the errors as they occur. Having a stable order
t
Is the current order defined in any way -- if not one should consider it
randoms anyways and as such actually randomizing should not make much of a
difference. FWIW I am fine with making it the default and outputting the
seed at the end of the run so it can reproduced. I am curious if it finds
For those that would rather it be opt-out, remember that we can always make
it opt-out later, once we have more experience with the feature.
Regarding the suggestion to have `--random 0` mean not to use randomizing,
I also think that could be confusing. 0 is also a valid integer seed, and
it se
> I usually agree with new features being opt-in, but perhaps this case is
> different?
>
> If I had tests that are breaking if executed randomly, I’d want to know
> about it yesterday. IOW, I’m having difficulty imagining a scenario where
> the user would be thankful for not activating this f
> On 10.03.2021., at 13:06, Mariusz Felisiak wrote:
>
>> I suggest we add the flag as "--random" taking an integer that is the seed,
>> or 0 to disable.
>
> This kind of APIs are always confusing. Moreover I don't think that changing
> the current behavior is a good idea, it should be opt-in n
Hi,
I agree that it would be a nice new feature.
*I suggest we add the flag as "--random" taking an integer that is the
> seed, or 0 to disable.*
>
This kind of APIs are always confusing. Moreover I don't think that
changing the current behavior is a good idea, it should be opt-in not
op
This would be something I'd really like to see. Also it would be nice to
make it the default.
I suggest we add the flag as "--random" taking an integer that is the seed,
or 0 to disable.
Do check out my project pytest-randomly for a battle-tested project
randomly shuffling tests.
One thing pytes
I'd like to ask folks if they would support reopening ticket #24522, which
is to add a --random option to Django's test runner:
https://code.djangoproject.com/ticket/24522
It was opened 6 years ago and closed as won't fix.
I've been doing some simplifications of the test-suite related code in
Dja
11 matches
Mail list logo
