-
Notifications
You must be signed in to change notification settings - Fork 887
feat: create e2e tests for organization custom roles page #15814
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
Conversation
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 was expecting assigning custom roles to be tested as part of this work, but we can do that in a separate PR if you'd like. It should basically be a copy+paste of the existing test for regular roles.
await deleteOrganization("testers"); | ||
}); | ||
|
||
test("create custom role with UI", async ({ page }) => { |
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.
why not make this a helper and call it from the other test rather than using the api?
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 have actually been going the route of having 2 different types of tests, one that starts with a change using the api and then completing the test through the UI and then another that does the same thing through the UI. I think there is the potential catching edge cases through this way of testing.
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.
@aslilac Looking around at many of the existing tests, I see this pattern when the same things to happen for many tests, for example creating a template, the API is used but then atleast one test would do the same thing through the UI if possible. I feel like this many be a bit more performant than going through the UI for every test. The except would be if there are many variations of path the user could take through the UI.
Adds 5 premium tests and 1 non-premium test.