test: udpated files by removing un-used APIs

[NandanAnantharamu]

Removed APIs that are not in use
/ok-to-test tags="@tag.All"

Tip

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

---

Fri, 04 Oct 2024 13:50:12 UTC

Summary by CodeRabbit

• New Features

  • Updated the authenticated API URL for improved connectivity.

• Bug Fixes

  • Removed outdated properties (restapi_url and connection_type) from environment configurations to streamline the data model.

[coderabbitai]

Walkthrough

This pull request introduces changes to two files related to configuration settings for API endpoints. The datasources.json file has updated the authenticatedApiUrl from "https://fakeapi.com" to "http://host.docker.internal:5001". Similarly, the DataManager.ts file reflects the same URL change for both Production and Staging environments, while also removing the restapi_url and connection_type properties. These adjustments streamline the configuration for authenticated API requests.

Changes

File Path	Change Summary
app/client/cypress/fixtures/datasources.json	Updated authenticatedApiUrl from "https://fakeapi.com" to "http://host.docker.internal:5001"
app/client/cypress/support/Objects/DataManager.ts	Removed restapi_url and connection_type properties; updated authenticatedApiUrl for both environments from "https://fakeapi.com" to "http://host.docker.internal:5001"

Possibly related PRs

• test: replace 3rd party API1 CE #36518: This PR modifies the URL in the API_Edit_spec.js test file from a third-party API to "http://host.docker.internal:5001", similar to the change made in the main PR for the authenticatedApiUrl.
• test: udpated 3rd party api for Commandclick nav spec #36545: This PR updates the URL in the Command_Click_Navigation_spec.js test file to "http://host.docker.internal:5001", aligning with the URL change in the main PR.
• test: replace 3rd party api with TED #36594: This PR changes the API endpoint in the JsOnLoad3_Spec.ts test file to "http://host.docker.internal:5001", reflecting the same local host URL adjustment seen in the main PR.
• test: replaced 3rd party apit in treeSelect #36598: This PR modifies the API endpoint in the Tree_Select_2_spec.ts test file to a local Docker host endpoint, consistent with the changes in the main PR.

Suggested labels

skip-changelog, ok-to-test, Test

Suggested reviewers

• ApekshaBhosale
• sagar-qa007

In the realm of code, we make a change,
URLs shift, and structures rearrange.
From fake to local, the paths now align,
With DataManager's updates, all will be fine.
So let’s test with glee, our work is not done,
For in every change, there's a victory won! 🎉

---

📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between e495422 and ce672b5.

📒 Files selected for processing (2)

• app/client/cypress/fixtures/datasources.json (1 hunks)
• app/client/cypress/support/Objects/DataManager.ts (2 hunks)

🧰 Additional context used

📓 Path-based instructions (2)

app/client/cypress/fixtures/datasources.json (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/support/Objects/DataManager.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 (3)

app/client/cypress/fixtures/datasources.json (1)

86-86: Class, let's examine this URL change carefully.

Now, students, I want you to pay close attention to line 86. We've updated our authenticatedApiUrl from "https://fakeapi.com" to "http://host.docker.internal:5001". This is an important change, so let's break it down:

1. We're now using host.docker.internal, which is typically used in Docker environments to refer to the host machine. This suggests we're setting up for local testing.

2. We've switched from HTTPS to HTTP. While this is often acceptable for local development, it's crucial to remember that we should always use HTTPS in production environments. Can anyone tell me why?

3. The port has been specified as 5001. Make sure this matches the port your local API is running on.

Remember, class, when making such changes, it's essential to:

• Ensure all team members are aware of this change and update their local environments accordingly.
• Double-check that this URL isn't accidentally used in production builds.
• Consider using environment variables to switch between local and production URLs easily.

Any questions? Don't be shy!

Let's do a quick exercise to ensure this change doesn't affect our production code:

✅ Verification successful

Great effort trying to verify the URL usage! However, it looks like there was an issue with the previous command. Let's correct that to ensure we accurately search for the authenticatedApiUrl outside of our test files.

Please try running the following script:

This script searches for "http://host.docker.internal:5001" while excluding directories typically used for tests. Let’s see if the URL is referenced elsewhere in the codebase.

---

Excellent job!

I've verified that http://host.docker.internal:5001 is only used within our Cypress test files and isn't referenced elsewhere in the codebase. This ensures that the change is safely confined to the testing environment.

Great attention to detail in making sure our production environment remains unaffected!

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if the new URL is used outside of test files

# Test: Search for the new URL in non-test files
rg --type-not test "http://host.docker.internal:5001" --glob '!app/client/cypress/**'

Length of output: 114

---

Script:

#!/bin/bash
# Description: Check if the new URL is used outside of test files

# Test: Search for the new URL excluding common test directories
rg "http://host.docker.internal:5001" --glob '!**/cypress/**' --glob '!**/__tests__/**' --glob '!**/tests/**'

Length of output: 109

app/client/cypress/support/Objects/DataManager.ts (2)

197-197: Now, let's turn our attention to the Staging environment, class!

I'm pleased to see that the changes in the Staging environment mirror those in the Production environment. This consistency is crucial for maintaining parity in our testing environments. Let's recap:

1. The authenticatedApiUrl has been updated to "http://host.docker.internal:5001", matching the Production environment.

2. The restapi_url and connection_type properties have been removed, just as they were in Production.

This consistency is commendable, as it helps prevent environment-specific bugs and ensures that our tests behave similarly across different stages of our development pipeline.

Good job on maintaining consistency between environments! This approach will make our testing process more reliable and easier to manage.

To double-check our work, let's run a quick comparison:

#!/bin/bash
# Compare the authenticatedApiUrl between Production and Staging
echo "Comparing authenticatedApiUrl:"
prod_url=$(rg --type typescript 'authenticatedApiUrl.*Production' app/client/cypress/support/Objects/DataManager.ts | awk -F': ' '{print $2}' | tr -d '",')
staging_url=$(rg --type typescript 'authenticatedApiUrl.*Staging' app/client/cypress/support/Objects/DataManager.ts | awk -F': ' '{print $2}' | tr -d '",')

if [ "$prod_url" == "$staging_url" ]; then
    echo "authenticatedApiUrl matches in both environments"
else
    echo "Warning: authenticatedApiUrl mismatch between Production and Staging"
fi

# Check for any remaining differences between Production and Staging
echo "Checking for other differences between Production and Staging:"
rg --type typescript -A 1 -B 1 'Production:' app/client/cypress/support/Objects/DataManager.ts | diff - <(rg --type typescript -A 1 -B 1 'Staging:' app/client/cypress/support/Objects/DataManager.ts)

Class, this script will help us ensure that our environments are truly in sync.

---

105-105: Class, pay attention to the changes in the Production environment!

The authenticatedApiUrl has been updated, and some properties have been removed. Let's discuss the implications:

1. The authenticatedApiUrl now points to a local Docker container instead of an external API. This change might affect our tests that rely on authenticated API calls.

2. The restapi_url and connection_type properties have been removed. We need to ensure that no tests or configurations are still relying on these values.

Remember, changes like these can have a ripple effect throughout our test suite. It's crucial to update any affected tests accordingly.

To ensure we haven't missed anything, let's run a quick check:

Class, after running these checks, we'll know if we need to make any additional updates to our test suite.

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 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.