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

Workflow E2E tests – batch 2 #9747

Merged
merged 9 commits into from
Jan 21, 2025
Merged

Workflow E2E tests – batch 2 #9747

merged 9 commits into from
Jan 21, 2025

Conversation

Devessier
Copy link
Contributor

@Devessier Devessier commented Jan 20, 2025

  • Fix the e2e according to the last changes in the workflows
  • Create a few more tests regarding the workflow visualizer

Copy link
Contributor

@greptile-apps greptile-apps bot left a 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.) in blank-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([
Copy link
Contributor

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.

Comment on lines +119 to +123
await Promise.all([
expect(workflowVisualizer.workflowStatus).toHaveText('Active'),

workflowVisualizer.activateWorkflowButton.click(),
]);
Copy link
Contributor

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.

Comment on lines +98 to +102
await Promise.all([
page.reload(),

expect(workflowVisualizer.triggerNode).toBeVisible(),
]);
Copy link
Contributor

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.

Copy link
Contributor

@prastoin prastoin left a 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([
Copy link
Contributor

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 )

Copy link
Contributor Author

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;
Copy link
Contributor

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

Copy link
Contributor

@thomtrp thomtrp left a 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';
Copy link
Contributor

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

Copy link
Contributor Author

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,
});
Copy link
Contributor

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?

Copy link
Contributor Author

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().

@Devessier Devessier force-pushed the workflow-e2e-batch-2 branch from c5a9fc9 to 281640b Compare January 21, 2025 10:33
@Devessier Devessier merged commit 8e0467e into main Jan 21, 2025
47 checks passed
@Devessier Devessier deleted the workflow-e2e-batch-2 branch January 21, 2025 10:46
Copy link

Fails
🚫

node failed.

Log

�[31mError: �[39m SyntaxError: Unexpected token C in JSON at position 0
    at JSON.parse (<anonymous>)
�[90m    at parseJSONFromBytes (node:internal/deps/undici/undici:5584:19)�[39m
�[90m    at successSteps (node:internal/deps/undici/undici:5555:27)�[39m
�[90m    at fullyReadBody (node:internal/deps/undici/undici:1665:9)�[39m
�[90m    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)�[39m
�[90m    at async specConsumeBody (node:internal/deps/undici/undici:5564:7)�[39m
danger-results://tmp/danger-results-8c32a146.json

Generated by 🚫 dangerJS against 281640b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants