-
Notifications
You must be signed in to change notification settings - Fork 6.1k
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
[Search]: Optimize search bar test suite #18375
Conversation
Uffizzi Preview |
719364b
to
ba4e2bf
Compare
act(() => { | ||
jest.advanceTimersByTime(200); | ||
}); | ||
await waitFor(() => expect(analyticsApiMock.getEvents()).toHaveLength(1)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test was flaky. Sometimes the value state was updated before the analytics events trigger, so here we inverted the checking, waiting for analytics events to be captured first. That way we know for sure that both value and events were updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, you could have one waitFor with two expect's at once in the inner function, to detach yourselves from any sequencing risks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @freben. I'm taking over this PR since @camilaibs is not available this week.
I'm not sure if I understood you 100%, if added baca931 with a fix attempt , could you take a look?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's what I had in mind, one waitFor with several expect inside.
I'm out for vacations now though!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet!
act(() => { | ||
jest.advanceTimersByTime(200); | ||
}); | ||
await waitFor(() => expect(analyticsApiMock.getEvents()).toHaveLength(1)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, you could have one waitFor with two expect's at once in the inner function, to detach yourselves from any sequencing risks
</SearchContextProvider> | ||
</TestApiProvider>, | ||
); | ||
|
||
const textbox = await screen.findByRole('textbox', { name: 'Search' }); | ||
const textbox = screen.getByLabelText('Search'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After fixing the other condition, does avoiding findByRole still make a measurable change in runtime? This one was a surprise for me for sure!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've ran the tests again with both options but didn't find a clear and relevant difference between both. I'm using yarn test plugins/search-react/src/components/SearchBar/SearchBar
and changing between both implementations.
But I see no reason to change it back. Do you have any worries keeping this line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, no worries. Just use what you feel is the clearest
ba4e2bf
to
baca931
Compare
Thanks for the contribution! |
Signed-off-by: Camila Belo <camilaibs@gmail.com>
Signed-off-by: Renan Mendes Carvalho <aitherios@gmail.com>
baca931
to
954a7d5
Compare
Hey, I just made a Pull Request!
In this pull request, we are seeking to make the speed of the SearchBar test more consistent and reduce its instability.
Performing the following test changes reduced the
SearchBar
test run time from27.501
seconds to6-9
seconds and could help us to reduce the risk of flakiness:Before optimizations
After optimizations
Watch Mode (Local)
In Band Mode (CI)
✔️ Checklist
Signed-off-by
line in the message. (more info)