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

chore: fetch spec with removed third party #36636

Merged
merged 9 commits into from
Oct 3, 2024

Conversation

sagar-qa007
Copy link
Contributor

@sagar-qa007 sagar-qa007 commented Oct 1, 2024

Description

Updated third party URLs.

Fixes #36437

Automation

/ok-to-test tags="@tag.JS"

🔍 Cypress test results

Tip

🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉
Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/11157028440
Commit: 3a3ab54
Cypress dashboard.
Tags: @tag.JS
Spec:


Thu, 03 Oct 2024 07:04:14 UTC

Communication

Should the DevRel and Marketing teams inform users about this change?

  • Yes
  • No

Summary by CodeRabbit

  • New Features

    • Enhanced fetch functionality with improved error handling and updated button interactions.
    • Introduced delay mechanism for fetch calls to ensure functionality after a timeout.
  • Bug Fixes

    • Updated button label and fetch endpoint to correctly retrieve and display user names.
  • Documentation

    • Updated test specifications to focus on server-side JavaScript function execution.

Copy link
Contributor

coderabbitai bot commented Oct 1, 2024

Walkthrough

The changes in this pull request primarily involve enhancements to the Cypress test suite, particularly focusing on server-side JavaScript function execution. Modifications include updating fetch call tests to ensure cookies are not sent, introducing delays in fetch calls, and altering button functionality to fetch user names instead of IDs. Additionally, the test specification file has been updated to reflect these changes, shifting the focus from client-side to server-side testing.

Changes

Files Change Summary
app/client/cypress/e2e/Regression/ServerSide/JsFunctionExecution/Fetch_Spec.ts Updated fetch tests to ensure cookies are not sent, added delay mechanisms, and modified button functionality to fetch user names.
app/client/cypress/limited-tests.txt Replaced entry for Fork_Template_spec.js with Fetch_Spec.ts, changing the focus of limited tests to server-side functionality.

Assessment against linked issues

Objective Addressed Explanation
Add skipped test cases to failure list for re-run (Task #36437) It's unclear if the changes directly address this requirement.

Possibly related PRs

  • fix: flaky mongo spec test #36220: Involves modifications to the Mongo_Spec.ts file, which is related to CRUD operations, similar to the fetch functionality enhancements in the main PR that also deals with API calls and data handling.
  • fix: mongo uri spec flakiness #36249: This PR focuses on CRUD operations in the MongoURI_Spec.ts file, which aligns with the main PR's emphasis on modifying fetch calls and improving data handling in tests.
  • test: replace 3rd party api with TED #36594: This PR replaces a third-party API with TED in the JsOnLoad3_Spec.ts file, which is relevant to the main PR's focus on enhancing fetch calls and API interactions within the test suite.

Suggested labels

Bug, Task, ok-to-test, Query & JS Pod, Integrations Product, Integrations Pod General

Suggested reviewers

  • ApekshaBhosale
  • jsartisan

🌟 In the land of code where fetch calls play,
A button now fetches names in a brand new way!
With tests that check cookies and delays in the mix,
The server-side magic is sure to fix!
So here’s to the changes, both clever and bright,
In the realm of Cypress, everything feels right! 🎉


🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@github-actions github-actions bot added the skip-changelog Adding this label to a PR prevents it from being listed in the changelog label Oct 1, 2024
@sagar-qa007
Copy link
Contributor Author

/ci-test-count-limit run_count=10

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Outside diff range and nitpick comments (1)
app/client/cypress/limited-tests.txt (1)

Line range hint 3-6: Excellent comments, class! Let's review them together.

These comments are like good instructions in your textbook. They clearly explain how to run all specs and the purpose of this file. Well done!

However, to make it even clearer for everyone, especially new students joining our class, we could add a bit more detail. What do you think about adding a brief explanation of what 'ci-test-limit' means? It's always good to spell out abbreviations!

Here's a suggestion to improve the last comment:

-#ci-test-limit uses this file to run minimum of specs. Do not run entire suite with this command.
+# The 'ci-test-limit' (Continuous Integration Test Limit) command uses this file to run a minimum set of specs.
+# Do not run the entire test suite with this command, as it's designed for quick, limited testing in the CI pipeline.

What do you think, class? Does this make it clearer for everyone?

🧰 Tools
🪛 LanguageTool

[uncategorized] ~1-~1: You might be missing the article “the” here.
Context: ... limited tests - give the spec names in below format: cypress/e2e/Regression/ServerSi...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 05d3822 and 4b38812.

📒 Files selected for processing (2)
  • app/client/cypress/e2e/Regression/ServerSide/JsFunctionExecution/Fetch_Spec.ts (1 hunks)
  • app/client/cypress/limited-tests.txt (1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
app/client/cypress/e2e/Regression/ServerSide/JsFunctionExecution/Fetch_Spec.ts (1)

Pattern app/client/cypress/**/**.*: Review the following e2e test code written using the Cypress test library. Ensure that:

  • Follow best practices for Cypress code and e2e automation.
  • Avoid using cy.wait in code.
  • Avoid using cy.pause in code.
  • Avoid using agHelper.sleep().
  • Use locator variables for locators and do not use plain strings.
  • Use data-* attributes for selectors.
  • Avoid Xpaths, Attributes and CSS path.
  • Avoid selectors like .btn.submit or button[type=submit].
  • Perform logins via API with LoginFromAPI.
  • Perform logout via API with LogOutviaAPI.
  • Perform signup via API with SignupFromAPI.
  • Avoid using it.only.
  • Avoid using after and aftereach in test cases.
  • Use multiple assertions for expect statements.
  • Avoid using strings for assertions.
  • Do not use duplicate filenames even with different paths.
  • Avoid using agHelper.Sleep, this.Sleep in any file in code.
app/client/cypress/limited-tests.txt (1)

Pattern app/client/cypress/**/**.*: Review the following e2e test code written using the Cypress test library. Ensure that:

  • Follow best practices for Cypress code and e2e automation.
  • Avoid using cy.wait in code.
  • Avoid using cy.pause in code.
  • Avoid using agHelper.sleep().
  • Use locator variables for locators and do not use plain strings.
  • Use data-* attributes for selectors.
  • Avoid Xpaths, Attributes and CSS path.
  • Avoid selectors like .btn.submit or button[type=submit].
  • Perform logins via API with LoginFromAPI.
  • Perform logout via API with LogOutviaAPI.
  • Perform signup via API with SignupFromAPI.
  • Avoid using it.only.
  • Avoid using after and aftereach in test cases.
  • Use multiple assertions for expect statements.
  • Avoid using strings for assertions.
  • Do not use duplicate filenames even with different paths.
  • Avoid using agHelper.Sleep, this.Sleep in any file in code.
🔇 Additional comments (2)
app/client/cypress/limited-tests.txt (1)

2-2: Class, let's examine this change in our test specification!

Now, pay attention to how we've shifted our focus from client-side template testing to server-side JavaScript function execution. This is quite a significant change, isn't it? We're moving from Fork_Template_spec.js to Fetch_Spec.ts.

Can anyone tell me what the change in file extension from .js to .ts might indicate? That's right! It suggests we're now using TypeScript, which gives us stronger typing. This is like using a more precise ruler in our measurements!

This change aligns well with our lesson plan of updating third-party URLs and improving our testing process. Remember, in software development, we're always looking to refine and improve our methods!

Let's do a quick exercise to verify this change:

Class, what do you think we'll find when we run this?

app/client/cypress/e2e/Regression/ServerSide/JsFunctionExecution/Fetch_Spec.ts (1)

81-81: Class, let's discuss the button label change.

Good job updating the button label to "getUserName"! This change accurately reflects the new functionality of fetching a user's name instead of their ID. Remember, clear and descriptive labels help improve the user experience and make our code more self-explanatory.

Comment on lines 84 to 98
`{{fetch('http://host.docker.internal:5001/v1/genderize_agify?name=sagar')
.then(res => {
if (!res.ok) {
throw new Error('Network response was not ok');
}
return res.json();
})
.then(json => {
const name = json.name; // Get the name
showAlert("Name: " + name);
})
.catch(error => {
console.error("Fetch error:", error);
showAlert("Failed to fetch user data: " + error.message);
})}}`
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Excellent work on improving the fetch call, but let's refine it further.

I'm impressed with the improvements you've made to the fetch call. The error handling is a great addition, showing good attention to potential issues. However, we need to make a few adjustments:

  1. Instead of using showAlert, let's use Cypress commands for assertions. This will make our tests more robust and easier to debug.
  2. We should avoid hardcoding URLs in our tests. Consider using environment variables or configuration files for the API endpoint.

Here's how we could improve this:

cy.intercept('GET', '**/v1/genderize_agify*').as('getUserName');
cy.get('[data-cy=getUserName]').click();
cy.wait('@getUserName').then((interception) => {
  expect(interception.response.statusCode).to.equal(200);
  expect(interception.response.body).to.have.property('name', 'sagar');
});

This approach uses Cypress commands for assertions and network interception, making our test more reliable and easier to maintain.

Comment on lines 102 to 103
agHelper.ClickButton("getUserName");
agHelper.AssertContains("Name: sagar", "exist");
Copy link
Contributor

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Let's improve our button selection and assertion, class.

While clicking the button and asserting the result is good, we can make it even better:

  1. Instead of using agHelper.ClickButton("getUserName"), let's use a data attribute for more reliable selection:

    cy.get('[data-cy=getUserName]').click();
  2. For the assertion, let's use Cypress commands instead of agHelper.AssertContains:

    cy.contains('Name: sagar').should('be.visible');

These changes will make our test more robust and easier to maintain. Remember, in Cypress, we always strive for clear, reliable selectors and assertions!

@sagar-qa007
Copy link
Contributor Author

/ci-test-count-limit run_count=10

@sagar-qa007
Copy link
Contributor Author

/ci-test-limit-count run_count=10

Copy link

github-actions bot commented Oct 2, 2024

Copy link

github-actions bot commented Oct 2, 2024

Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/11144425433.
Cypress dashboard url: Click here!
All Cypress tests have passed 🎉🎉🎉

***** Repeat Run Summary ***** Total Tests with repeat: 30 Total Passed: 20 Total Failed: 10 Total Skipped: 0 *****************************

@sagar-qa007
Copy link
Contributor Author

/ci-test-limit-count run_count=10

Copy link

github-actions bot commented Oct 3, 2024

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 4b38812 and 20018d4.

📒 Files selected for processing (1)
  • app/client/cypress/e2e/Regression/ServerSide/JsFunctionExecution/Fetch_Spec.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
app/client/cypress/e2e/Regression/ServerSide/JsFunctionExecution/Fetch_Spec.ts (1)

Pattern app/client/cypress/**/**.*: Review the following e2e test code written using the Cypress test library. Ensure that:

  • Follow best practices for Cypress code and e2e automation.
  • Avoid using cy.wait in code.
  • Avoid using cy.pause in code.
  • Avoid using agHelper.sleep().
  • Use locator variables for locators and do not use plain strings.
  • Use data-* attributes for selectors.
  • Avoid Xpaths, Attributes and CSS path.
  • Avoid selectors like .btn.submit or button[type=submit].
  • Perform logins via API with LoginFromAPI.
  • Perform logout via API with LogOutviaAPI.
  • Perform signup via API with SignupFromAPI.
  • Avoid using it.only.
  • Avoid using after and aftereach in test cases.
  • Use multiple assertions for expect statements.
  • Avoid using strings for assertions.
  • Do not use duplicate filenames even with different paths.
  • Avoid using agHelper.Sleep, this.Sleep in any file in code.
🔇 Additional comments (1)
app/client/cypress/e2e/Regression/ServerSide/JsFunctionExecution/Fetch_Spec.ts (1)

84-106: Excellent implementation of error handling and retries in fetchData

Dear students, you've done a commendable job incorporating error handling and a retry mechanism within your fetchData function. This demonstrates a solid understanding of asynchronous operations and resilience in network requests.

);

Copy link
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue

Avoid using agHelper.Sleep(), utilize proper synchronization methods

Class, it's important to remember that using agHelper.Sleep() is discouraged in our testing code. Relying on arbitrary sleep durations can lead to flaky tests and inefficient execution.

Please consider removing agHelper.Sleep(2000); and instead use Cypress's built-in commands for synchronization. For instance, you can use cy.wait() with aliases to wait for specific network calls or cy.get() to wait for elements to appear before interacting with them.

Copy link

github-actions bot commented Oct 3, 2024

Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/11155403098.
Cypress dashboard url: Click here!
All Cypress tests have passed 🎉🎉🎉

***** Repeat Run Summary ***** Total Tests with repeat: 30 Total Passed: 20 Total Failed: 10 Total Skipped: 0 *****************************

@sagar-qa007
Copy link
Contributor Author

/ci-test-limit-count run_count=10

Copy link

github-actions bot commented Oct 3, 2024

@sagar-qa007
Copy link
Contributor Author

/ci-test-limit-count run_count=10 runId=11155992956

Copy link

github-actions bot commented Oct 3, 2024

@sagar-qa007
Copy link
Contributor Author

/ci-test-limit-count run_count=10 runId=11155992956

Copy link

github-actions bot commented Oct 3, 2024

Copy link

github-actions bot commented Oct 3, 2024

Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/11155992956.
Cypress dashboard url: Click here!
All Cypress tests have passed 🎉🎉🎉

***** Repeat Run Summary ***** Total Tests with repeat: 30 Total Passed: 20 Total Failed: 10 Total Skipped: 0 *****************************

Copy link

github-actions bot commented Oct 3, 2024

Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/11156361022.
Cypress dashboard: Click here!
The following are new failures, please fix them before merging the PR:
To know the list of identified flaky tests - Refer here

***** Repeat Run Summary ***** Total Tests with repeat: 30 Total Passed: 30 Total Failed: 0 Total Skipped: 0 *****************************

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (2)
app/client/cypress/e2e/Regression/ServerSide/JsFunctionExecution/Fetch_Spec.ts (2)

Line range hint 15-40: Class, let's improve our test assertions and avoid sleeps!

While your test structure is good, we need to make a few improvements:

  1. Instead of using showAlert for assertions, let's use Cypress commands. This will make our tests more robust and easier to debug. Here's how we can refactor this:
cy.window().its('store').invoke('dispatch', { type: 'FETCH_USER_DETAILS' }).then((response) => {
  expect(response.username).to.equal('anonymousUser');
});
  1. We should avoid using agHelper.Sleep(2000). In Cypress, we want our tests to be deterministic. Instead, let's use Cypress's built-in waiting mechanisms:
cy.get('@jsObject').should('exist');

Remember, class, in Cypress, we always strive for clear, reliable selectors and assertions!


Line range hint 41-76: Let's refine our testing approach, class!

Your test structure for checking fetch with setTimeout is on the right track, but we can make it even better:

  1. Instead of using agHelper.Sleep(3000), let's utilize Cypress's built-in waiting mechanisms. We can intercept the network request and wait for it:
cy.intercept('GET', '/api/v1/users/me').as('getUser');
jsEditor.SelectFunctionDropdown("invoker");
jsEditor.RunJSObj();
cy.wait('@getUser');
  1. For our assertion, instead of using agHelper.AssertContains, let's use Cypress commands:
cy.contains('anonymousUser').should('be.visible');

Remember, in Cypress, we always aim for deterministic tests that don't rely on arbitrary timeouts. Keep up the good work, and let's make our tests even more robust!

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between d71687c and 3a3ab54.

📒 Files selected for processing (1)
  • app/client/cypress/e2e/Regression/ServerSide/JsFunctionExecution/Fetch_Spec.ts (2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
app/client/cypress/e2e/Regression/ServerSide/JsFunctionExecution/Fetch_Spec.ts (1)

Pattern app/client/cypress/**/**.*: Review the following e2e test code written using the Cypress test library. Ensure that:

  • Follow best practices for Cypress code and e2e automation.
  • Avoid using cy.wait in code.
  • Avoid using cy.pause in code.
  • Avoid using agHelper.sleep().
  • Use locator variables for locators and do not use plain strings.
  • Use data-* attributes for selectors.
  • Avoid Xpaths, Attributes and CSS path.
  • Avoid selectors like .btn.submit or button[type=submit].
  • Perform logins via API with LoginFromAPI.
  • Perform logout via API with LogOutviaAPI.
  • Perform signup via API with SignupFromAPI.
  • Avoid using it.only.
  • Avoid using after and aftereach in test cases.
  • Use multiple assertions for expect statements.
  • Avoid using strings for assertions.
  • Do not use duplicate filenames even with different paths.
  • Avoid using agHelper.Sleep, this.Sleep in any file in code.
📓 Learnings (1)
app/client/cypress/e2e/Regression/ServerSide/JsFunctionExecution/Fetch_Spec.ts (4)
Learnt from: sagar-qa007
PR: appsmithorg/appsmith#34955
File: app/client/cypress/e2e/Regression/ClientSide/ActionExecution/General_settings_Spec.ts:14-56
Timestamp: 2024-07-16T06:44:55.263Z
Learning: Avoid using sleep functions like `agHelper.Sleep`, `this.Sleep` in Cypress tests within the `app/client/cypress` directory to prevent non-deterministic behaviors and ensure tests are more reliable and maintainable.
Learnt from: sagar-qa007
PR: appsmithorg/appsmith#34955
File: app/client/cypress/e2e/Regression/ClientSide/ActionExecution/General_settingsTe_Spec.ts:33-33
Timestamp: 2024-07-16T08:25:23.799Z
Learning: Avoid using sleep functions like `agHelper.Sleep` and `this.Sleep` in Cypress tests within the `app/client/cypress` directory to prevent non-deterministic behaviors and ensure tests are more reliable and maintainable.
Learnt from: sagar-qa007
PR: appsmithorg/appsmith#35412
File: app/client/cypress/e2e/Regression/ClientSide/OneClickBinding/TableWidget/mysql_spec.ts:99-99
Timestamp: 2024-08-06T05:59:19.000Z
Learning: In Cypress tests within the `app/client/cypress` directory, avoid using `agHelper.Sleep`, `this.Sleep`, and other related sleep functions to prevent non-deterministic behaviors and ensure tests are more reliable and maintainable. Instead, use Cypress methods like `cy.get()`, `cy.contains()`, and `cy.intercept()` to wait for specific conditions.
Learnt from: ApekshaBhosale
PR: appsmithorg/appsmith#35412
File: app/client/cypress/e2e/Regression/ClientSide/OneClickBinding/TableWidget/mysql_spec.ts:99-99
Timestamp: 2024-08-06T05:39:47.929Z
Learning: In Cypress tests, avoid using `agHelper.Sleep` as it can lead to flaky tests and unnecessary delays. Instead, use Cypress methods like `cy.get()`, `cy.contains()`, and `cy.intercept()` to wait for specific conditions.

@sagar-qa007 sagar-qa007 added the ok-to-test Required label for CI label Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ok-to-test Required label for CI skip-changelog Adding this label to a PR prevents it from being listed in the changelog
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants