Skip to content

Fix statistics reporting when running under pytest-xdist#1577

Merged
Zac-HD merged 1 commit into
HypothesisWorks:masterfrom
Zac-HD:xdist-reporting
Dec 11, 2018
Merged

Fix statistics reporting when running under pytest-xdist#1577
Zac-HD merged 1 commit into
HypothesisWorks:masterfrom
Zac-HD:xdist-reporting

Conversation

@Zac-HD

@Zac-HD Zac-HD commented Sep 14, 2018

Copy link
Copy Markdown
Member

Closes #700.

I moved some reporting code to Statistics.get_description(), because xdist can move lists of strings between processes but not arbitrary objects. Hopefully this will be useful for future work on #437.

@Zac-HD Zac-HD force-pushed the xdist-reporting branch 2 times, most recently from 0f072ab to 2ca37a5 Compare September 15, 2018 05:43
@Zac-HD Zac-HD added the enhancement it's not broken, but we want it to be better label Sep 17, 2018
'\n'.join(item.hypothesis_report_information)
))
if hasattr(item, 'hypothesis_statistics') and report.when == 'teardown':
# Running on pytest <= 3.5 where user_properties doesn't exist, fall

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This says <= 3.5 but the code before checks for < 3.5. Which is it?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code is correct, and the comment now fixed.

terminalreporter.write_line(' - Test was never run')
continue
if LooseVersion(pytest.__version__) < '3.5': # pragma: no cover
if terminalreporter.config.getoption('-n'):

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like a very fragile way to check if a plugin is enabled. Is there really not a better one?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope 😭

We can robustly check if the xdist plugin is installed, and we can robustly check if the current process one of the workers (and if so which one), but there's no way I can find to distinguish between being the master process and xdist not being enabled.

(I did add a check for the --numprocesses form, even though I've never seen it in the wild)

' * %s' % (event,)
)
terminalreporter.write_line('')
for test_report in terminalreporter.stats['']:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is .stats[''] in this context?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Magic. It's the only place the list of TestReport objects seems to be stored; I copied this from an example plugin and it works even though I can't find where the entry is added to the dict.

I've added a comment which will would help me debug it when if this breaks later. Fortunately we have tests that will fail immediately if it does!

@DRMacIver DRMacIver left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I confess I don't entirely understand the pytest interaction, but I think that's more because pytest than anything you can fix! At any rate, the testing looks good, and it's at least better than the status quo, so LGTM. :shipit:

@Zac-HD Zac-HD merged commit 62d83ba into HypothesisWorks:master Dec 11, 2018
@Zac-HD Zac-HD deleted the xdist-reporting branch December 11, 2018 12:53
@Zac-HD

Zac-HD commented Dec 11, 2018

Copy link
Copy Markdown
Member Author

Mmm, suffice to say that Pytest has taken a variety of approaches that I would not choose over the years, and that the xdist plugin is an old-school hack job. Though I do have a pytest commit bit too, so cast not the first stone etc... 😬 At this point there's a clear migration towards clearer and more idiomatic Python, but compatibility has it's costs too.

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

Labels

enhancement it's not broken, but we want it to be better

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants