Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use a dedicated TestResult object instead of keeping ConjectureData around #1820

Merged
merged 1 commit into from
Feb 21, 2019

Conversation

DRMacIver
Copy link
Member

The main motivation for doing this was memory usage, but I think it actually makes the API much cleaner to have a logical distinction between its data and its result, and it's something I've vaguely felt I should do for a while but never got around to.

@Zac-HD Zac-HD added the performance go faster! use less memory! label Feb 19, 2019
@Zalathar
Copy link
Contributor

Is #411 still relevant here, or is it fine for this type to be named TestResult?

@Zac-HD
Copy link
Member

Zac-HD commented Feb 20, 2019

Is #411 still relevant here, or is it fine for this type to be named TestResult?

If it's something we should avoid doing, it would be good to add a linter for it (in another PR). flake8-alfred looks like it can only scan for exact matches, but I think git grep "def test|class Test" -- hypothesis-python/src/hypothesis is probably enough to handle this case!

The specific reason to avoid this no longer applies to modern versions of Pytest, but it's a good general principle and we do support and test against older versions where it would matter.

@DRMacIver
Copy link
Member Author

Is #411 still relevant here, or is it fine for this type to be named TestResult?

Oh yeah, that's a good shout. It's not fine and I'll change the name.

@DRMacIver DRMacIver force-pushed the DRMacIver/test-results branch from 3b71149 to 4cb61c1 Compare February 20, 2019 09:47
@DRMacIver
Copy link
Member Author

If it's something we should avoid doing, it would be good to add a linter for it (in another PR). flake8-alfred looks like it can only scan for exact matches, but I think git grep "def test|class Test" -- hypothesis-python/src/hypothesis is probably enough to handle this case!

One thing worth noting is that currently we have some methods which this would catch, and those aren't problems as long as they don't belong to a class named Test*. It's only top level functions that are a problem.

An alternative way we could lint this is that we could check that there are no globals in a Hypothesis test package that start with Test or test and come from a Hypothesis module and aren't the stateful testing TestCase (maybe the check here could be that they're imported with the same name as their original name - so this would fail because we call those globals TestFoo).

@Zac-HD
Copy link
Member

Zac-HD commented Feb 20, 2019

git grep "^def test|^class Test" -- hypothesis-python/src/hypothesis then! If we can't do it with grep I wouldn't bother; a more complicated check will probably take more effort to maintain than it saves.

Copy link
Contributor

@Zalathar Zalathar left a comment

Choose a reason for hiding this comment

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

Other than that possible tweak to coverage, this all looks good to me.

@DRMacIver DRMacIver merged commit c2c26ec into master Feb 21, 2019
@DRMacIver DRMacIver deleted the DRMacIver/test-results branch February 21, 2019 12:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance go faster! use less memory!
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants