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 E2E tests on Windows #76

Merged
merged 41 commits into from
Jun 17, 2024
Merged

Fix E2E tests on Windows #76

merged 41 commits into from
Jun 17, 2024

Conversation

mokagio
Copy link
Contributor

@mokagio mokagio commented May 2, 2024

Update: Rebased on top of #99. The diff is noisy because it includes the changes from #17, too.
Update2: Merged trunk to the branch and solved conflicts. Shouldn't be noisy anymore.
Update3: Merged trunk to the branch and scope of this PR changes to fixing tests for Windows


Works on my machine™

image

Let's see what CI does...


Proposed Changes

The PR adds E2E tests to Buildkite pipeline.

Testing Instructions

  1. Confirm E2E tests run successfully in Buildkite

Pre-merge Checklist

  • Have you checked for TypeScript, React or other console errors?

<div
className="flex flex-row flex-grow"
data-testid="onboarding"
>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We could actually remote this, given the current code doesn't use it because I couldn't get it to work.

const frontendUrl = await siteContent.frontendButton.textContent();
expect( frontendUrl ).toBeTruthy();
expect( frontendUrl ).not.toBeNull();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It might be better to make this "to not be empty"

e2e/sites.test.ts Outdated Show resolved Hide resolved
Comment on lines 18 to 38
get siteNameInput() {
return this.locator.getByLabel( 'Site name' );
}

get sitePathInput() {
return this.locator.getByLabel( 'Local path' );
}

get continueButton() {
return this.locator.getByRole('button', { name: 'Continue' });
}

private get localPathButton() {
return this.locator.getByTestId( 'select-path-button' );
}

// This usually opens an OS folder dialog, except we can't interact with it in playwrite.
// In tests the dialog returns the value of the E2E_OPEN_FOLDER_DIALOG environment variable.
async clickLocalPathButtonAndSelectFromEnv() {
await this.localPathButton.click();
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Part of this logic is duplicated from add-site-modal.ts. I shall extract it in a site-form.ts object, but maybe in a followup PR. Very keen to get E2E back to stable in CI.

@mokagio mokagio mentioned this pull request May 8, 2024
1 task
@mokagio mokagio changed the base branch from mokagio/macos-e2e-tests to mokagio/e2e-fix-locally May 9, 2024 02:47
mokagio added a commit that referenced this pull request May 16, 2024
In #17 ,
6619e75 , we duplicated the logic to
run unit tests and linters on Buildkite.

After running them side by side for a few days, no issues have been
reported.

It's now time to remove the GitHub Actions step.

See #99 and
#76 for the E2E counterpart.
@wojtekn wojtekn changed the title Fix E2E tests Fix E2E tests on Windows Jun 5, 2024
@wojtekn
Copy link
Contributor

wojtekn commented Jun 5, 2024

Thanks @mokagio. I merged the other branch, merged trunk to this one, and changed PR title to account for its reduced scope.

@fluiddot
Copy link
Contributor

fluiddot commented Jun 5, 2024

@wojtekn @fluiddot, if that's okay with you, I'd like to merge the macOS work in the meantime. See #207.

Sounds good. Thanks @wojtekn for reviewing and merging it 🙇 .

@fluiddot
Copy link
Contributor

fluiddot commented Jun 5, 2024

I managed to reproduce the issue by downloading the binary generated in CI. However, it only fails when running E2E tests. If I open the executable and create a site, it copies all WordPress files 🙃.

After adding more logs, I realized that the problem is related to not waiting for the server files to be copied before using the app. In general, this is not a problem as by the time you interact with the app the copy operation is finished. This log entry (reference) should have happened before creating the site.

In e2e tests actions are executed as soon as the window is ready, so the combination of copy operation being a bit slower on Windows and creating a site right after the app is opened is resulting in a race condition problem. I'll solve this by moving the setupWPServerFiles call to be invoked when the app is ready but before the main window is created. This way we'll ensure that all server files are copied.

@fluiddot
Copy link
Contributor

fluiddot commented Jun 5, 2024

I managed to address the issue about the site folder but the test case delete site is still failing. As far as I've checked, there seems to be an error on that specific action. I'll keep investigating...

UPDATE: As expected, the delete action is failing with the error Error: Failed to perform delete operation.

@mokagio
Copy link
Contributor Author

mokagio commented Jun 6, 2024

Great job @fluiddot !

I managed to address the issue about the site folder but the test case delete site is still failing. As far as I've checked, there seems to be an error on that specific action. I'll keep investigating...

At least it's progress 😄

@mokagio
Copy link
Contributor Author

mokagio commented Jun 6, 2024

@fluiddot

I realized that the problem is related to not waiting for the server files to be copied before using the app. In general, this is not a problem as by the time you interact with the app the copy operation is finished. This log entry (reference) should have happened before creating the site.

In e2e tests actions are executed as soon as the window is ready, so the combination of copy operation being a bit slower on Windows and creating a site right after the app is opened is resulting in a race condition problem. I'll solve this by moving the setupWPServerFiles call to be invoked when the app is ready but before the main window is created. This way we'll ensure that all server files are copied.

Just for my understanding, the fix you implemented is at the app runtime level, not in the E2E tests, right?

If I understand correctly, the unusual setup in the tests brought to light a design flaw that was present but hard to run into when interacting with the app as a human. If that's the case, I'll add this to my collection of examples of how testing helps discover edge cases 😄

(If instead I have misunderstood, then that's good too as it's an occasion for me to learn more)

@fluiddot
Copy link
Contributor

fluiddot commented Jun 6, 2024

Just for my understanding, the fix you implemented is at the app runtime level, not in the E2E tests, right?

If I understand correctly, the unusual setup in the tests brought to light a design flaw that was present but hard to run into when interacting with the app as a human. If that's the case, I'll add this to my collection of examples of how testing helps discover edge cases 😄

(If instead I have misunderstood, then that's good too as it's an occasion for me to learn more)

Exactly, here's the fix I applied. The issue is more prone to happen on E2E due to the fact that UI interaction happens quickly. Still, I presume it could be reproducible if you open the app and click on the "Add Site" button right away. Additionally, if disk operations are slow in the machine, this would be also easier to experience.

@fluiddot
Copy link
Contributor

fluiddot commented Jun 6, 2024

I tried different approaches to solve the error when deleting a site but none have proven to work (reference). I tested locally and all E2E tests pass, so I'm thinking of disabling that test case temporarily on Windows. WDYT?

@wojtekn
Copy link
Contributor

wojtekn commented Jun 10, 2024

I tested locally and all E2E tests pass, so I'm thinking of disabling that test case temporarily on Windows. WDYT?

@fluiddot makes sense, let's do it. We can have a proper comment there and come back to that in the future, and still benefit from running other tests on Windows.

This test case fails when running in CI but not locally. Until we find a workaround, we'll temporarily disable it.
This is mostly needed for Windows because some operations take longer, like creating a site.
@fluiddot
Copy link
Contributor

I continued exploring the needed workarounds to unblock this PR and managed the E2E tests to pass in a separate branch with the following changes:

  • Fix race condition when setting up server files: As mentioned here, the fact that you can create a site before the operation of copying the WordPress server files finishes might result in an exception. This should be uncommon as the copy operation should be fast. However, I noticed in the Windows CI machine that copying the bundled copy of WordPress can take around 30 seconds. Probably, this is potentially related to Microsoft Defender slowing down the process.
  • Increase E2E timeouts: Some of the actions like creating a site take longer on Windows, hence we need to increase the timeouts to avoid the failure.
  • Skip delete site test on Windows: As shared here, I couldn't find a solution for the delete site test case. Until we find a workaround, we'll temporarily disable it.

Since this PR is related to E2E, I'm also going to apply the following changes:

  • Re-enable E2E tests on Windows (seems they were disabled after updating with trunk).
  • Disable unit tests temporarily on Windows until we find a solution to the failures.

cc @mokagio

@fluiddot fluiddot marked this pull request as ready for review June 12, 2024 12:24
@fluiddot fluiddot self-assigned this Jun 12, 2024
@fluiddot fluiddot requested review from a team June 12, 2024 12:25
@fluiddot
Copy link
Contributor

@mokagio I took the liberty to set the PR ready for review as all CI jobs are passing (816fbb9) 🎊 . Let me know if you have any thoughts/concerns about this, thanks 🙇 !

@mokagio
Copy link
Contributor Author

mokagio commented Jun 17, 2024

Excellent! Thanks @fluiddot

@mokagio mokagio merged commit c34d313 into trunk Jun 17, 2024
12 checks passed
@mokagio mokagio deleted the mokagio/e2e-fix-attempt branch June 17, 2024 10:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants