-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
E2e Test Fixes #25058
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
E2e Test Fixes #25058
Conversation
should check if Firefox can be re-enabled or if it's still failing. |
Co-authored-by: delvh <[email protected]>
I've reenabled. I've been running it on my fork for a while and haven't seen it fail yet. 👍 As far as other tests go, do you have any recommendations for pieces of the front-end we know are fragile or we've run into issues repeatedly? |
Nothing really comes to mind, but if you are looking for something to test, I'd say the PR flow is something that would be nice to have, e.g.
Part of this flow is already covered by backend integration tests, but it should really be moved to E2E instead and out of backend integration tests. |
Maybe also start simpler:
|
fmt.Printf("%v", stderr.String()) | ||
log.Fatal("Playwright Failed: %s", err) | ||
} else { | ||
fmt.Printf("%v", stdout.String()) |
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'm surposed ths fmt.Printf
passes the linter.
@@ -0,0 +1,56 @@ | |||
// @ts-check |
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.
What's this for?
@@ -53,7 +47,7 @@ export async function save_visual(page) { | |||
timeout: 20000, | |||
mask: [ | |||
page.locator('.dashboard-navbar span>img.ui.avatar'), | |||
page.locator('.ui.dropdown.jump.item span>img.ui.avatar'), | |||
page.locator('.ui.dropdown.jump.item.tooltip span>img.ui.avatar'), |
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 better selector available? Maybe add a class name? This will break too easily.
await page.waitForLoadState('networkidle'); | ||
await page.locator('input#user_name').fill('user2'); | ||
await page.locator('input#password').fill('password'); | ||
await page.locator('form button.ui.green.button:visible').click(); |
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.
Also a rather suboptimal selector. Afraid we have to add some class names to make tests more robust against class name changes.
await page.locator('input#email').fill(`e2e-test-${workerInfo.workerIndex}@test.com`); | ||
await page.locator('input#password').fill('test123'); | ||
await page.locator('input#retype').fill('test123'); | ||
await page.locator('form button.ui.green.button:visible').click(); |
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.
Same here.
Stale for long time. Continue or close? |
@kdumontnu The same question is still in my mind .... is the e2e testing system really used or useful? After years, I can see it only consumes some CI resources but no test is really written. So, maybe removing the e2e testing system is also a choice? |
I think the decision must be:
The e2e tests have certainly not been very helpful as written, which has certainly surprised me. There are some improvements that can be made to make them run more efficiently & reliably, but I don’t think that’s the major issue. Rather, it seems we’re not finding value in it. I use them extensively in my fork to ensure I don’t regress on front-end features. @wxiaoguang @silverwind @kerwin612 you do a lot of the front-end development recently. I think we should reflect on:
Some categories of “issues” I can think of are:
There are certainly different solutions to these. For instance, we could have integration tests request templates to catch 500 errors. Some of them I think are still best solved with e2e tests. I think migrating to typescript is an incredible help. One thing I like to mention is that you are able to make contributions to the code base because you understand a lot of the nuances, but it’s difficult to scale that, which is why I suggest we focus on reviews and new contributions in the evaluation. Happy to get everyone’s opinion though because I agree that e2e tests are not working right now |
I use playwright testing in other applications and find those tests to be valuable to assert that the UI is working on a very basic level. log in, log out, assert certain elements are present/absent before/after login state change. I'm only also only using chrome in these tests, for the sake of having them as stable as possible. I have not investigated how gitea's e2e tests work in detail or why they even include go code, but that go code seems superflous. e2e tests should just compile and start the app ( |
Or maybe we can move these tests to a standalone repository. |
Absolute no from me. Test code needs to be in the same repo as the code being tested. |
I will answer from my side:
Various edge cases or design problems.
Same as above, various edge cases or design problems.
Improve the whole framework to make code easy to write and avoid low-level mistakes.
There used to be a lot, most of them are caused by hacky patches/abuses/pollution. After recent years refactoring, the whole situation is much better now.
It could be covered by backend tests (and it is easier to be covered by backend tests because backend code could mock data more easily)
I guess it is still a framework problem. At least, my new proposal "global init" will resolve most problems.
E2e test could do better in this field
E2e test could do better in this field. Since we do not use cutting edge browser features, most modern browsers behave the same with our code.
Not really related to e2e test The really problem is:
|
Keep those e2e tests as minimal as possible. Complex tests offer little value and are prone to introduce flakiness and if they are testing too specific things, they prevent progress as some maintainers may not be willing to even touch e2e tests. I could for example see value in having e2e that just visit a few pages and assert that the browser console does not log any errors. Some recent problems would have been caught by this. |
I will disable the e2e test in CI (#34262) since it fails with new playwright and there is no active maintainer for it. The e2e test related code is still in code base, feel free to maintain it if anyone uses it. |
-> update go&js dependencies #34262 Feel free to reopen if there would be new progresses. Thank you very much! |
To Do:
Bump playwrightand review test setup