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

ref(symbolicator): Add tests for LPQ tasks #29088

Merged
merged 10 commits into from
Oct 8, 2021
Merged

ref(symbolicator): Add tests for LPQ tasks #29088

merged 10 commits into from
Oct 8, 2021

Conversation

relaxolotl
Copy link
Contributor

Adds in some basic tests for the LPQ tasks.

@relaxolotl relaxolotl requested review from flub, Swatinem, loewenheim and a team October 5, 2021 20:57
Copy link
Member

@Swatinem Swatinem left a comment

Choose a reason for hiding this comment

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

lgtm, though I have no idea how the mocking is supposed to work

Comment on lines 43 to 44
# TODO: i am bad at python
STORE
Copy link
Member

Choose a reason for hiding this comment

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

what were you trying to do? :-D

Copy link
Contributor Author

Choose a reason for hiding this comment

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

pylance was telling me to use this :(

)


STORE = create_store()
Copy link
Contributor

Choose a reason for hiding this comment

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

this is unfortunately an anti-pattern. You should make this a fixture:

@pytest.fixture
def store() -> RedisRealtimeMetricsStore:
    return ...

And you'll find you won't need to go back to unittests' TestCase and .tearDown() below.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i can make this a fixture, but i'm unsure how to guarantee that the functions i'm testing will be using that store returned by the fixture.

should scan_for_suspect_projects and update_lpq_eligibility take in an optional store parameter and use that instead of whatever it imports from realtime metrics? or is it possible to return a fixture in a @mock.patch?

Copy link
Contributor Author

@relaxolotl relaxolotl Oct 8, 2021

Choose a reason for hiding this comment

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

a potential workaround to ensure that test data isn't leaking between stores is to just modify the internally-stored prefix on the store. if these tests are being run in parallel that might just cause race issues due to the store flip-flopping between different prefixes...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i figured it out, pushed changes

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants