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

[FIX] web: tests: fix randomly failing load state tests #162939

Conversation

aab-odoo
Copy link
Contributor

Before this commit, several qunit load state tests sometimes failed. They all follow the same pattern:

  • trigger an "hashchange" event to simulate an update of the url
  • wait twice for nextTick
  • check the DOM reflects the url change

However, waiting for 2 ticks isn't enough. Indeed, when the url hash is set, our mock location object dispatches a "real" hashchange event on window, but it does it after a setTimeout [1]. Then, the webclient is notified (via the router service) of the url change, and reacts by loading the appropriate action. This then requires 2 ticks, because we first clear the DOM with the BlankComponent, and then we mount the requested action/view.

This commit makes those tests more robust by waiting for a setTimeout before the 2 nextTicks.

[1]

window.setTimeout(() => {

Runbot issue~37030

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:


I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

@robodoo
Copy link
Contributor

robodoo commented Apr 23, 2024

Pull request status dashboard.

Before this commit, several qunit load state tests sometimes
failed. They all follow the same pattern:
  - trigger an "hashchange" event to simulate an update of the url
  - wait twice for nextTick
  - check the DOM reflects the url change

However, waiting for 2 ticks isn't enough. Indeed, when the url
hash is set, our mock location object dispatches a "real" hashchange
event on window, but it does it after a setTimeout [1]. Then, the
webclient is notified (via the router service) of the url change,
and reacts by loading the appropriate action. This then requires
2 ticks, because we first clear the DOM with the BlankComponent,
and then we mount the requested action/view.

This commit makes those tests more robust by waiting for a
setTimeout before the 2 nextTicks.

[1] https://github.com/odoo/odoo/blob/1882d8f89f760bd1ff8a2bf0ae798939402647a3/addons/web/static/tests/setup.js#L52

Runbot issue~37030
@aab-odoo aab-odoo force-pushed the 17.0-fix-load-state-undeterministic-tests-aab branch from a5a1575 to c38447b Compare April 23, 2024 07:28
@kebeclibre
Copy link
Contributor

robodoo r+

@C3POdoo C3POdoo added the RD research & development, internal work label Apr 23, 2024
robodoo pushed a commit that referenced this pull request Apr 23, 2024
Before this commit, several qunit load state tests sometimes
failed. They all follow the same pattern:
  - trigger an "hashchange" event to simulate an update of the url
  - wait twice for nextTick
  - check the DOM reflects the url change

However, waiting for 2 ticks isn't enough. Indeed, when the url
hash is set, our mock location object dispatches a "real" hashchange
event on window, but it does it after a setTimeout [1]. Then, the
webclient is notified (via the router service) of the url change,
and reacts by loading the appropriate action. This then requires
2 ticks, because we first clear the DOM with the BlankComponent,
and then we mount the requested action/view.

This commit makes those tests more robust by waiting for a
setTimeout before the 2 nextTicks.

[1] https://github.com/odoo/odoo/blob/1882d8f89f760bd1ff8a2bf0ae798939402647a3/addons/web/static/tests/setup.js#L52

Runbot issue~37030

closes #162939

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
@robodoo robodoo closed this in 1a66729 Apr 23, 2024
willylohws pushed a commit to willylohws/odoo that referenced this pull request May 1, 2024
Before this commit, several qunit load state tests sometimes
failed. They all follow the same pattern:
  - trigger an "hashchange" event to simulate an update of the url
  - wait twice for nextTick
  - check the DOM reflects the url change

However, waiting for 2 ticks isn't enough. Indeed, when the url
hash is set, our mock location object dispatches a "real" hashchange
event on window, but it does it after a setTimeout [1]. Then, the
webclient is notified (via the router service) of the url change,
and reacts by loading the appropriate action. This then requires
2 ticks, because we first clear the DOM with the BlankComponent,
and then we mount the requested action/view.

This commit makes those tests more robust by waiting for a
setTimeout before the 2 nextTicks.

[1] https://github.com/odoo/odoo/blob/1882d8f89f760bd1ff8a2bf0ae798939402647a3/addons/web/static/tests/setup.js#L52

Runbot issue~37030

closes odoo#162939

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
@fw-bot fw-bot deleted the 17.0-fix-load-state-undeterministic-tests-aab branch May 7, 2024 11:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RD research & development, internal work
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants