-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Workflow E2E tests – batch 2 #9747
Conversation
Devessier
commented
Jan 20, 2025
•
edited
Loading
edited
- Fix the e2e according to the last changes in the workflows
- Create a few more tests regarding the workflow visualizer
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.
PR Summary
This PR enhances workflow E2E testing capabilities with comprehensive test coverage for workflow creation, modification, and status management.
- Added workflow trigger types (
record-created
,record-updated
, etc.) and action types (create-record
,update-record
, etc.) inblank-workflow.ts
for standardized testing - Implemented robust step management methods (createStep, deleteStep) with response validation and error handling
- Added three comprehensive E2E tests covering workflow creation, step deletion persistence, and active workflow modification
- Enhanced test selection capabilities by adding
data-testid
attribute to workflow status container - Introduced proper test cleanup with workflow deletion after each test run
3 file(s) reviewed, 3 comment(s)
Edit PR Review Bot Settings | Greptile
|
||
await stepNode.click(); | ||
|
||
await Promise.all([ |
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.
logic: Potential race condition in deleteStep between visibility check and actual deletion. Node might become invisible for other reasons.
await Promise.all([ | ||
expect(workflowVisualizer.workflowStatus).toHaveText('Active'), | ||
|
||
workflowVisualizer.activateWorkflowButton.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.
logic: Race condition risk - activateWorkflowButton.click() should be awaited before checking workflowStatus. The Promise.all here could lead to flaky tests.
await Promise.all([ | ||
page.reload(), | ||
|
||
expect(workflowVisualizer.triggerNode).toBeVisible(), | ||
]); |
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.
logic: Potential race condition between page reload and trigger node visibility check. Consider awaiting page load event first.
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.
That's a really nice refactor and POM implem
|
||
await workflowVisualizer.deleteStep(fifthStepId); | ||
|
||
await expect(workflowVisualizer.getAllStepNodes()).toContainText([ |
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.
Remark: This might be HA but I feel the following operation could be factorized in a loop:
await expect(workflowVisualizer.getAllStepNodes()).toContainText(ACTIONS);
await expect(workflowVisualizer.getAllStepNodes()).toHaveCount(COUNT);
await workflowVisualizer.deleteStep(CURR_STEP);
In my opinion would make it easier to read and allow a better extensibility in case we create a new workflow actions in the future ? ( If the test has for goal to always create all of them in once workflow, if it's even possible )
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 thought about doing a loop, but I'm unsure if it would make the test's code more transparent. In the test, I'm alternatively deleting the first and last nodes of the flow. I prefer dumb code instead of writing complex code to reach the same goal.
I'm open to trying different patterns in e2e tests so we find the best one for the team.
export class WorkflowVisualizerPage { | ||
#page: Page; | ||
|
||
workflowId: string; | ||
workflowName: string; | ||
|
||
readonly addStepButton: Locator; |
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.
Praise love all of it
77a5a52
to
c5a9fc9
Compare
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.
Those are great 🔥 Do you keep deactivation for later?
| 'update-record' | ||
| 'delete-record' | ||
| 'code' | ||
| 'send-email'; |
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.
maybe types should go in a separated file. I feel like you will need it in other tests
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.
Done. Thank you!
}); | ||
this.deactivateWorkflowButton = page.getByLabel('Deactivate Workflow', { | ||
exact: true, | ||
}); |
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 do we have deactivate and activate?
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 do you mean by this question?
This code sets up some "locators". We should think about Playwright's locators as CSS selectors. A string containing a CSS selector won't be resolved until we provide it to document.querySelector()
.
Here, I declare how we can find the activate and deactivate buttons. However, these locators will only be resolved when I use them with expect(locator)
or locator.click()
.
c5a9fc9
to
281640b
Compare
Log
|