Skip to content

xdist is not executing tests if their parametrizations were collected in a different order #596

Description

@pytestbot

Originally reported by: BitBucket: liori, GitHub: liori


Related to #594, but slightly different.

I generated my parametrizations by iterating over a set of strings. However, this iteration depends on the specific values the strings hash to, and these values might be different for every process. Therefore, whereas I was always generating exactly the same parametrizations, they were in different order.

A simple test case that shows the problem:

#!python

import pytest

my_names = {'john', 'kate', 'alfred', 'paul', 'mary'}

@pytest.mark.parametrize('name', list(my_names), ids=list(my_names))
def test_is_name_short(name):
    assert len(name) < 7

Run with PYTHONHASHSEED=random py.test -n 4 to make sure you trigger randomized hashing for strings.

I think that a simple sort in report_collection_diff before running unified_diff might help with this problem.


Activity

  1. pytestbot commented on Sep 23, 2014

    @pytestbot
    ContributorAuthor

    Original comment by Bruno Oliveira (BitBucket: nicoddemus, GitHub: nicoddemus):


    I don't think that will solve it, because the master node in xdist uses just the indices to distribute the tests among the slaves and if each slave has its own list ordered differently it may end up not running some tests while running others twice.

    I'm not sure how to approach this. Unfortunately there's no way for parametrization to realize that its parameters may be random.

  2. pytestbot commented on Sep 23, 2014

    @pytestbot
    ContributorAuthor

    Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):


    I think we just need to fail with clear error message if the collections are non-deterministic. The only way how xdist could work there is, if we ran one node and then forked it N times but even that would only work on Unix and only for "-nN", not for cross-host/interpreter distribution etc.

  3. pytestbot commented on Sep 23, 2014

    @pytestbot
    ContributorAuthor

    Original comment by Bruno Oliveira (BitBucket: nicoddemus, GitHub: nicoddemus):


    Perhaps we should put a warning in xdist's documentation regarding random collections? Perhaps even pointing to the code you posted in #594 as an possible solution.

  4. pytestbot commented on Sep 24, 2014

    @pytestbot
    ContributorAuthor

    Original comment by BitBucket: liori, GitHub: liori:


    Bruno Oliveira, I just wanted to point out that the #594 is not mine ;-) It's just a coincidence that pytry had a similar problem two days ago. Also, it won't work here—you can't move this nondeterminism into the test function itself in this case.

    Also, I'd like to underline that the parametrization values here are deterministic (not random like in #594), just the order of them is not. That's why enforcing some order (by sorting the test identifiers) will be sufficient in this case to have exactly the same order in all slaves.

    If you say that xdist distributes only indices, then indeed sorting in report_collection_diff will not be enough. However, sorting somewhere before that point should still be OK—somewhere where the order of tests after sorting will be preserved till the test distribution phase. I don't know the xdist codebase, but I'd guess that sorting the test by their identifiers on each slave should enforce the same order everywhere. Then using indices will be perfectly safe.

  5. pytestbot commented on Sep 24, 2014

    @pytestbot
    ContributorAuthor

    Original comment by Bruno Oliveira (BitBucket: nicoddemus, GitHub: nicoddemus):


    You're right, if files were sorted in each slave, everyone would end up with the exact test ids and ordering. Not sure how that fits with overall py.test's design thought, as this would change the test execution order significantly.

    Personally, I think requiring tests to be collected always in the same order is fine, only that right now the end user doesn't have a clear message stating the problem; if we could solve that, then it is usually a simple matter to just fix the offending tests' parametrization.

  6. pytestbot commented on Sep 24, 2014

    @pytestbot
    ContributorAuthor

    Original comment by BitBucket: liori, GitHub: liori:


    I would really love to see the solution for this problem inside xdist instead of my tests—for obvious reasons. But I'll understand if you choose not to implement it there; after all, the multiprocessing code is already quite complex. Anyway, big thanks for the module, it saves me quite a lot of time now.

  7. added
    type: bugproblem that needs to be addressed
    plugin: xdistrelated to the xdist external plugin
    on Jun 15, 2015
  8. added 2 commits that reference this issue on Jun 18, 2016
    01fe780
    cec0f41
  9. RonnyPfannschmidt commented on Jan 18, 2017

    @RonnyPfannschmidt
    Member

    closing this one as "works as intended" - currently pytest cant support anything else due to allowing duplicate test id's

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    plugin: xdistrelated to the xdist external plugintype: bugproblem that needs to be addressed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions