test: executing skipped tests on CE #36681
Conversation
NandanAnantharamu
requested review from
ApekshaBhosale and
sagar-qa007
as code owners
WalkthroughThe changes in this pull request focus on enhancing the Cypress end-to-end test suites across various components of the application. Several test cases that were previously skipped have been activated, allowing them to run and contribute to the overall test coverage. Modifications include updates to the logic and assertions within these tests, ensuring they accurately validate the intended functionality of widgets and CRUD operations. Additionally, the Changes
Suggested labels
Suggested reviewers
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? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
Documentation and Community
|
|
/ci-test-limit |
github-actions
bot
added
skip-changelog
|
Tests running at: https://github.com/appsmithorg/appsmith/actions/runs/11163507163. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Outside diff range and nitpick comments (25)
app/client/cypress/e2e/Regression/ClientSide/ActionExecution/ActionSelectorCreateShouldBind_spec.ts (1)
15-15: Class, let's review this test case activation!Good job on activating this important test case! It's like turning on the lights in a dark classroom - now we can see what's really going on. However, there are a few areas where we can improve our test-writing skills:
Remember, children, we should avoid using
cy.waitin our code. It's like waiting for the bell to ring - not very efficient! Instead, let's use Cypress's built-in retry-ability and wait for specific elements or conditions.We're not using data-* attributes for our selectors. It's like trying to find a book without looking at its title! Let's use more specific and reliable selectors.
We haven't performed a login via API. It's like sneaking into the classroom without signing in at the office! We should use
LoginFromAPIto ensure we're properly authenticated.Let's work on these improvements to make our test even better!
Would you like to see an example of how we can refactor this test to address these points?
app/client/cypress/e2e/Regression/ClientSide/BugTests/DatasourceSchema_spec.ts (2)
51-51: Class, let's examine this change closely.Students, we've removed the
.skipfrom this test case, which means it will now be executed along with the other tests. This is a positive step towards improving our test coverage.However, I'd like to point out a few areas where we can make improvements:
- The use of
agHelper.Sleep(1500)goes against our best practices. Remember, we should avoid using sleep functions in our tests.- The comment above the test case mentions a bug ([Bug]: Remove duplicate schema API calls on expanding entity even after Refresh #36348). We should update or remove this comment if the bug has been resolved.
- The test case uses
agHelper.VerifyCallCount(@getDatasourceStructure, 1), which is good for checking API calls, but we should also include assertions about the actual behavior or state changes we expect.Let's work on refactoring this test to address these points. Who would like to volunteer to make these improvements?
Here's a suggested refactoring:
it("2. Verify if schema is fetched once", () => { agHelper.RefreshPage(); EditorNavigation.SelectEntityByName( dataSourceName, EntityType.Datasource ); // Use a more reliable wait strategy agHelper.WaitUntilAllApiFinish(); cy.intercept('GET', '/api/v1/datasources/*/structure').as('getDatasourceStructure'); agHelper.VerifyCallCount(`@getDatasourceStructure`, 1); // Add assertions about the expected state after fetching the schema agHelper.AssertElementExist(dataSources._dsTabSchema); // Add more specific assertions here AppSidebar.navigate(AppSidebarButton.Editor); EditorNavigation.SelectEntityByName("Query1", EntityType.Query); agHelper.ActionContextMenuWithInPane({ action: "Delete", entityType: entityItems.Query, }); dataSources.DeleteDatasourceFromWithinDS(dataSourceName); });Remember, clear and reliable tests are the foundation of a robust application. Let's strive for excellence in our test suite!
Line range hint
1-138: Class, let's summarize our review.We've examined the changes made to our datasource schema test suite. The primary modification was enabling a previously skipped test case, which is a step in the right direction for improving our test coverage.
However, there are a few general observations about the entire test suite that we should address:
Consistency: Some tests use the
it.skip()syntax while others don't. We should standardize our approach to skipping tests across the entire suite.Test isolation: Several tests are modifying shared state (like creating and deleting datasources). We should ensure each test properly sets up and tears down its own environment to prevent inter-test dependencies.
Error handling: We should add more robust error handling and logging to help diagnose issues when tests fail.
Documentation: While the test descriptions are generally clear, we could benefit from more detailed comments explaining the purpose and expected outcomes of each test.
For your homework, I'd like each of you to review one of the other test cases in this file and propose improvements based on these observations. Remember, clear and maintainable tests are crucial for the long-term health of our project.
Any questions before we move on to our next topic?
app/client/cypress/e2e/Regression/ClientSide/Binding/DatePicker_Text_spec.js (4)
Line range hint
17-52: Well done, class! This test case has been successfully unskipped.I'm pleased to see that you've activated this important test case. It thoroughly examines the binding between DatePicker1 and the Text widget, covering both editor and deploy modes. Your use of appropriate assertions and avoidance of cy.wait is commendable.
However, let's strive for excellence! Consider enhancing this test by using data-* attributes for selectors instead of classes or IDs. This will make your tests more resilient to UI changes.
For example, you could refactor this line:
cy.get(publishPage.datepickerWidget + commonlocators.inputField).eq(0).click();to use a data attribute like this:
cy.get('[data-cy="datepicker1-input"]').click();Don't forget to add the corresponding data-cy attribute to your component!
Line range hint
54-90: Excellent work on unskipping this test, students!I'm impressed by your attention to detail in testing the date change scenario. Your test effectively validates the binding between DatePicker1 and the Text widget when the date is modified.
However, let's take this opportunity for a quick lesson on code optimization. I noticed that you're using
cy.log()for debugging. While this is helpful during development, it's best to remove or comment out these logs in the final version of your tests.Consider removing or commenting out debug logs like this one:
cy.log("retured date" + date);This will make your tests cleaner and more focused on the actual assertions. Remember, clean code is happy code!
Line range hint
92-103: A gold star for unskipping this crucial test!Your diligence in verifying that changes in DatePicker1 don't affect DatePicker2 is commendable. This test ensures the independence of our date picker components, which is vital for maintaining a robust application.
However, let's take a moment to reflect on our test structure. While your test is effective, we could make it even better by following the Arrange-Act-Assert (AAA) pattern more explicitly.
Consider restructuring your test like this:
it("3. Validate the Date is not changed in DatePicker2", function () { // Arrange const initialDatePicker2Value = dateDp2; // Act // (The action of changing DatePicker1 is performed in the previous test) // Assert cy.get(formWidgetsPage.datepickerWidget + commonlocators.inputField) .eq(1) .should("have.value", initialDatePicker2Value); _.deployMode.DeployApp(); // Assert in deploy mode cy.get(publishPage.datepickerWidget + commonlocators.inputField) .eq(1) .should("have.value", initialDatePicker2Value); _.deployMode.NavigateBacktoEditor(); });This structure makes the test's intention clearer and easier to understand. Remember, clear tests lead to clear minds!
Line range hint
127-151: Bravo on unskipping this test, young scholars!Your attention to both positive and negative scenarios in this test is exemplary. By verifying the behavior of the onDateSelected action for both selection and deselection of a date, you're ensuring robust functionality of our DatePicker component.
However, let's take this opportunity to discuss the importance of consistent naming conventions. Your test description starts with a verb in present tense, which differs from the other test cases.
Consider rephrasing your test description to match the style of the other tests:
it("5. Validate onDateSelected action triggers on selection but not on deselection", function () { // ... (rest of the test remains the same) });Remember, consistency in naming makes our test suite easier to read and understand. It's like keeping your desk tidy - it helps you find what you need more quickly!
app/client/cypress/e2e/Regression/ClientSide/Autocomplete/JS_AC2_spec.ts (1)
Line range hint
114-180: Class, let's review the changes in our test suite!Good job on unskipping this important test case! It's crucial to ensure our autocomplete functionality works correctly. However, there are a few areas where we can improve:
Remember to use data-* attributes for selectors. This makes our tests more robust and less prone to breaking due to UI changes.
Consider using more descriptive names for our test cases. Instead of "3. Bug [Bug]-[350]:Random keystrokes trigger autocomplete to show up #15429...", we could use something like "Autocomplete should not appear for random keystrokes".
Let's break down this large test into smaller, more focused tests. Each assertion could potentially be its own test case, making it easier to identify specific issues if the test fails.
Here's a little homework assignment for you:
- Add data-* attributes to the elements you're interacting with in the test.
- Refactor the test into smaller, more focused test cases.
- Use more descriptive names for each test case.
Remember, clear and focused tests make for happy developers! Keep up the good work!
app/client/cypress/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker2_spec.js (2)
Line range hint
22-50: Class, let's review this test case together!Good job on activating this previously skipped test case. It's like waking up a sleeping student in class! However, we need to make a few improvements to follow our best practices:
Instead of using string selectors like
formWidgetsPage.datepickerWidget, we should use data-* attributes. This makes our selectors more robust and less likely to break with UI changes.We're not seeing any login process here. Remember, it's important to use LoginFromAPI for authentication in our tests. This ensures consistency and speed in our test setup.
While we're using helper functions like SetDateToToday(), which is great, we could further improve by creating more reusable functions for common actions.
Let's work on these improvements to make our test even better!
Would you like to see an example of how we could refactor this test case?
Line range hint
1-217: Let's look at the big picture, class!While we've made progress with our DatePicker tests, there's still room for improvement:
We have several commented-out test cases. These are like unfinished homework assignments! We should either complete these tests or remove them if they're no longer relevant.
Our active test cases could benefit from the same improvements we discussed earlier:
- Use data-* attributes for selectors
- Implement LoginFromAPI for authentication
- Create more reusable helper functions
Remember to avoid using
cy.wait()andagHelper.sleep(). Instead, use Cypress's built-in retry-ability and assertions to wait for elements or states.Let's ensure we're using
LogOutviaAPIfor logging out at the end of our tests.Consider grouping related tests using
describeblocks for better organization.Class, let's work together to refactor these tests and make them shine!
Would you like a homework assignment to refactor one of these test cases as an example?
app/client/cypress/e2e/Regression/ClientSide/Widgets/Tab/Tabs_2_spec.ts (4)
Line range hint
70-93: Good job on covering all the basics, students!Your test case is like a well-rounded lesson plan, covering all the important topics. However, let's add a little more clarity to our work. Consider adding a comment before each section to explain what we're testing. For example:
// Test renaming entityExplorer.RenameEntityFromExplorer("Tabs1", "NewTabs", true); // Test copy-paste using keyboard shortcuts EditorNavigation.SelectEntityByName("NewTabs", EntityType.Widget); // ... rest of the codeThis will make it easier for your classmates to understand your test at a glance. Remember, clear communication is key in both coding and teaching!
Line range hint
95-110: Excellent work on testing widget binding, class!Your test case is like a well-constructed experiment, testing both the tab selection and visibility binding. To make your experiment even more robust, consider adding a small wait after toggling the visibility:
propPane.TogglePropertyState("visible", "Off"); agHelper.Sleep(500); // Add a small wait agHelper.AssertText(locators._textInside, "text", "false");This will ensure that the UI has had time to update before we check the result. Remember, in both science experiments and coding tests, timing can be crucial!
Line range hint
121-168: An impressive, comprehensive test case, class! You're really diving deep into the subject matter.Your test is like a thorough examination, covering multiple aspects of tab management across different application modes. Well done! To make this test even better, consider breaking it down into smaller, more focused test cases. For example:
it("5a. Verify tab visibility settings", () => { // Test visibility toggle }); it("5b. Verify tab behavior in preview mode", () => { // Test preview mode }); it("5c. Verify tab behavior in deploy mode", () => { // Test deploy mode }); it("5d. Verify tab deletion and addition", () => { // Test delete and add operations });This approach will make your tests more modular and easier to maintain, just like breaking down a complex lesson into smaller, manageable topics. Keep up the excellent work!
Line range hint
250-288: Excellent work on error handling, students! You're thinking like true quality assurance professionals!Your test case is like a well-designed experiment, checking not just for the presence of errors, but also their persistence. This attention to detail is commendable!
To make your test even more organized, consider using Cypress's
contextto group related tests. For example:context("Default tab validation", () => { it("shows error for non-existent tab name", () => { // Test for "Tab 11" }); it("persists error message after page reload", () => { // Test for "Tab 13" and page reload }); });This structure will make your test suite even more readable and maintainable. Keep up the great work in ensuring our code behaves correctly, even when given incorrect input!
app/client/cypress/e2e/Regression/ClientSide/Widgets/Multiselect/MultiSelect5_spec.ts (1)
Line range hint
312-362: Class, let's review this test case together!Good job on activating this previously skipped test case! It's like turning on a light in a dark room - now we can see what's going on with those pesky validation errors.
Here's what you did well:
- You've avoided using cy.wait, cy.pause, and agHelper.sleep(). That's music to my ears!
- You're using propPane and agHelper methods for interactions. Gold star for you!
- No XPaths or CSS selectors in sight. You're learning well!
However, there's always room for improvement. Let's work on these areas:
- Your assertions could use more descriptive messages. Remember, good assertions are like good explanations - the more detail, the better!
- Some of your steps could be grouped into reusable custom commands. Think of it like creating a new vocabulary word - it makes your code easier to read and understand.
Here's a little homework for you:
- Add more descriptive messages to your assertions. For example:
agHelper.VerifyEvaluatedErrorMessage( "Some or all default values are missing from options. Please update the values.", "Validation error should appear when default values are not in options" );- Consider creating custom commands for repeated actions. For instance:
Cypress.Commands.add('updateMultiSelectProperty', (propertyName, value) => { propPane.UpdatePropertyFieldValue(propertyName, value); });Keep up the good work, and remember: in the world of testing, clarity is king!
app/client/cypress/e2e/Regression/ServerSide/GenerateCRUD/MySQL2_Spec.ts (2)
Line range hint
194-238: Now, let's review the content of our newly activated test case.The test case is well-structured and covers important aspects of table functionality. However, there are a few areas where we can improve:
Avoid using hard-coded waits:
Instead ofagHelper.Sleep(3000), consider using Cypress's built-in waiting mechanisms or custom commands that wait for specific elements or states.Assertion improvements:
Use more specific assertions when possible. For example, instead of just checking if the JSON form is visible, assert its content or structure.Table navigation:
The test navigates through pages, which is good. However, consider adding more assertions to verify the correct data is displayed on each page.Error handling:
Add error handling for cases where expected elements are not found or actions fail.Here's an example of how we could refactor a part of this test:
- table.NavigateToNextPage(true, "v2"); //page 2 - agHelper.Sleep(3000); //wait for table navigation to take effect! - table.WaitUntilTableLoad(0, 0, "v2"); //page 2 + table.NavigateToNextPage(true, "v2"); + cy.get('.t--table-widget').should('be.visible').and('contain', 'Page 2'); + table.WaitUntilTableLoad(0, 0, "v2");This change replaces the hard-coded wait with a more specific assertion that the table is visible and contains "Page 2".
Consider adding more descriptive comments to explain the purpose of each section of the test. This will help future maintainers understand the test's flow and intentions.
Line range hint
1-238: Class, let's summarize our review of this test suite.Overall, this test suite for MySQL CRUD operations is comprehensive and well-structured. The activation of the previously skipped test case is a positive step towards improving our test coverage.
However, there are several areas where we can enhance our test suite:
- Replace hard-coded waits with Cypress's built-in waiting mechanisms or custom commands.
- Use more specific assertions to verify the correct behavior and data.
- Improve error handling to make tests more robust.
- Add more descriptive comments to explain the purpose and flow of each test section.
Remember, continuous improvement is key in software development. Let's strive to make our tests not just functional, but exemplary!
Consider breaking down this large test file into smaller, more focused test files. This will improve maintainability and make it easier to run specific tests when needed. For example, you could have separate files for create, read, update, and delete operations.
app/client/cypress/e2e/Regression/ClientSide/Git/GitSync/SwitchBranches_spec.js (5)
Line range hint
200-200: Remember: Avoid usingcy.wait()for synchronizationDear student, relying on fixed waits like
cy.wait(4000);can make your tests unreliable. It's better to wait for specific elements or conditions using Cypress's built-in commands to ensure your tests are robust and efficient.Consider replacing the fixed wait with a conditional wait. For example:
-cy.wait(4000); // wait for switch branch +cy.get(gitSyncLocators.branchSwitchLoader).should('not.exist');
Line range hint
254-255: Reminder: Replace fixed waits with conditional waitsDear student, using fixed waits like
cy.wait(400);andcy.wait(4000);can impact test reliability and speed. Please use Cypress commands that wait for specific conditions instead.Replace with conditional waits such as:
-cy.wait(400); +cy.get(gitSyncLocators.branchListItem).should('be.visible'); -cy.wait(4000); +PageLeftPane.switchSegment(PagePaneSegment.UI);
Line range hint
258-258: Use data- attributes instead of CSS selectors*Dear student, using CSS selectors like
".t--canvas-artboard"is discouraged. Please use data-* attributes for selectors to make your tests more robust.Update the selector to use a data-* attribute:
-cy.get(".t--canvas-artboard").should("be.visible"); +cy.get("[data-testid='canvas-artboard']").should("be.visible");
Line range hint
195-197: Utilize data- attributes for better selector reliability*Dear student, selecting elements using CSS classes such as
".ads-v2-spinner"and".t--widget-tablewidgetv2"can lead to brittle tests. It's best to use data-* attributes which are less likely to change.Update your selectors accordingly:
-cy.get(".ads-v2-spinner").should("exist"); +cy.get("[data-testid='ads-spinner']").should("exist"); -cy.get(".ads-v2-spinner").should("not.exist"); +cy.get("[data-testid='ads-spinner']").should("not.exist"); -cy.get(".t--widget-tablewidgetv2").should("not.exist"); +cy.get("[data-widget='tablewidgetv2']").should("not.exist");
Line range hint
323-325: Avoid usingafterin your test casesDear student, it's recommended to avoid using
afterandafterEachin your tests to prevent unintended side effects. Instead, manage cleanup within each test or in abeforeEachblock.Please refactor your code to remove the
afterblock.app/client/cypress/e2e/Regression/ClientSide/Git/GitSync/GitSyncedApps_spec.js (1)
Line range hint
428-456: Avoid Using CSS Class Selectors; Prefer Locator Variables with Data AttributesDear students, remember that relying on CSS class selectors like
".t--import-json-card"can make your tests fragile. Instead, we should use locator variables that leverage data attributes for better stability.Please consider the following improvements:
Replace:
-cy.get(".t--import-json-card").next().click();With:
+cy.get(importPageLocators.importJsonCard).next().click();Ensure that
importPageLocators.importJsonCardis defined using a data attribute selector.Similarly, for the entity items:
-cy.get(".t--entity-item").eq(1).contains("crudpage_1"); -cy.get(".t--entity-item").eq(2).contains("crudpage_1 Copy"); -cy.get(".t--entity-item").eq(3).contains("ApiCalls_1"); -cy.get(".t--entity-item").eq(4).contains("ApiCalls_1 Copy"); -cy.get(".t--entity-item").eq(5).contains("Child_Page");Should be replaced with:
+cy.get(entityExplorerLocators.entityItems).eq(1).contains("crudpage_1"); +cy.get(entityExplorerLocators.entityItems).eq(2).contains("crudpage_1 Copy"); +cy.get(entityExplorerLocators.entityItems).eq(3).contains("ApiCalls_1"); +cy.get(entityExplorerLocators.entityItems).eq(4).contains("ApiCalls_1 Copy"); +cy.get(entityExplorerLocators.entityItems).eq(5).contains("Child_Page");Ensure
entityExplorerLocators.entityItemsuses data attribute selectors.This approach will make your tests more maintainable and less prone to breakage due to UI changes.
app/client/cypress/e2e/Sanity/Datasources/MsSQL_Basic_Spec.ts (1)
Line range hint
163-163: Please avoid usingagHelper.Sleep(); use explicit waits insteadDear students, I noticed that you're using
agHelper.Sleep()in your test cases on lines 163, 169, 183, and 189. While it might seem convenient, relying on arbitrary sleep durations can lead to unstable and flaky tests. It's important to use explicit waits or assertions to ensure the application is in the desired state before proceeding. This approach makes your tests more reliable and efficient.Also applies to: 169-169, 183-183, 189-189
app/client/cypress/e2e/Regression/ServerSide/GenerateCRUD/MySQL1_Spec.ts (1)
262-264: Consider marking unimplemented tests as skippedThe test case for verifying add/update/delete on new records is currently not implemented. To prevent it from running unintentionally, you can mark it as skipped using
it.skip.Would you like assistance in implementing this test case or help in opening a GitHub issue to track this task?
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (15)
- app/client/cypress/e2e/Regression/ClientSide/ActionExecution/ActionSelectorCreateShouldBind_spec.ts (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Autocomplete/JS_AC2_spec.ts (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Binding/DatePicker_Text_spec.js (4 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Binding/SelectWidget_Spec.ts (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/BugTests/DatasourceSchema_spec.ts (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Git/GitSync/GitSyncedApps_spec.js (2 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Git/GitSync/SwitchBranches_spec.js (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker2_spec.js (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker_With_Switch_spec.js (2 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Widgets/Multiselect/MultiSelect5_spec.ts (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Widgets/Tab/Tabs_2_spec.ts (1 hunks)
- app/client/cypress/e2e/Regression/ServerSide/GenerateCRUD/MySQL1_Spec.ts (2 hunks)
- app/client/cypress/e2e/Regression/ServerSide/GenerateCRUD/MySQL2_Spec.ts (1 hunks)
- app/client/cypress/e2e/Sanity/Datasources/MsSQL_Basic_Spec.ts (1 hunks)
- app/client/cypress/limited-tests.txt (1 hunks)
🧰 Additional context used
📓 Path-based instructions (15)
app/client/cypress/e2e/Regression/ClientSide/ActionExecution/ActionSelectorCreateShouldBind_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/e2e/Regression/ClientSide/Autocomplete/JS_AC2_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/e2e/Regression/ClientSide/Binding/DatePicker_Text_spec.js (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/e2e/Regression/ClientSide/Binding/SelectWidget_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/e2e/Regression/ClientSide/BugTests/DatasourceSchema_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/e2e/Regression/ClientSide/Git/GitSync/GitSyncedApps_spec.js (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/e2e/Regression/ClientSide/Git/GitSync/SwitchBranches_spec.js (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/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker2_spec.js (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/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker_With_Switch_spec.js (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/e2e/Regression/ClientSide/Widgets/Multiselect/MultiSelect5_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/e2e/Regression/ClientSide/Widgets/Tab/Tabs_2_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/e2e/Regression/ServerSide/GenerateCRUD/MySQL1_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/e2e/Regression/ServerSide/GenerateCRUD/MySQL2_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/e2e/Sanity/Datasources/MsSQL_Basic_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 (10)
app/client/cypress/limited-tests.txt (1)
2-15: Well done, class! These additions are commendable.I'm pleased to see such a comprehensive list of test files being added to our test suite. This demonstrates a strong commitment to thorough testing, which is crucial for maintaining a robust application. Let's break down what we're seeing here:
- We have tests covering various datasources, like MsSQL and MySQL.
- There are tests for client-side functionalities such as Autocomplete, DatePicker, and Multiselect widgets.
- We're also testing important features like Git sync and CRUD operations.
Remember, children, comprehensive testing is like doing all your homework - it might seem like a lot of work, but it ensures you're prepared for any surprises that might come up later!
app/client/cypress/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker_With_Switch_spec.js (3)
31-31: Well done, class! You've successfully activated this test case.I'm pleased to see that you've removed the
.skipmodifier from this test case. This change aligns perfectly with our lesson objective of executing previously skipped tests. Remember, every test is an opportunity to learn and improve our code!
54-54: Excellent work on activating another test case!I'm thrilled to see that you've removed the
.skipmodifier from this test case as well. This change is in perfect harmony with our lesson plan of executing previously skipped tests. Keep up the good work, and remember, every test we run brings us closer to a more robust application!
Line range hint
1-74: A+ for your diligent work on this file!Class, I'm impressed with the changes made to this test suite. By removing the
.skipmodifiers, you've ensured that these important tests will now be executed. This aligns perfectly with our lesson objective of improving test coverage.A few reminders for future assignments:
- Continue to avoid using
cy.waitandcy.pausein your code.- Remember to use data-* attributes for selectors instead of XPaths or CSS paths.
- Keep using
LoginFromAPI,LogOutviaAPI, andSignupFromAPIfor authentication operations.Overall, excellent job on making these tests active while maintaining good Cypress testing practices!
app/client/cypress/e2e/Regression/ClientSide/Widgets/Tab/Tabs_2_spec.ts (4)
Line range hint
20-68: Well done, class! This test case is a shining example of good practices.I'm pleased to see you've organized your assertions into logical groups. It's like having a well-organized classroom where everything has its place. Keep up the good work!
Line range hint
112-119: A concise and effective test, students! Gold star for you!This test case is like a clear, focused question on a pop quiz. It checks one specific behavior and does it well. You've shown that you understand the importance of testing both the "on" and "off" states. Keep up this level of precision in your future tests!
Line range hint
170-178: A short but sweet test case, students! You've hit the mark!This test is like a quick pop quiz that tests a specific feature effectively. You've shown that you understand the importance of checking both minimum and maximum limits. It's concise yet covers the essential aspects of the auto height feature. Excellent work!
Line range hint
192-248: Bravo, class! This test case is a masterpiece of style verification!Your test is like a comprehensive art critique, examining every aspect of the Tabs widget's appearance. You've covered colors, borders, shadows, and even tested the color picker functionality. The use of JS mode for background color shows you're thinking outside the box - excellent!
I'm particularly impressed by your attention to detail in checking CSS properties directly. This ensures that what we see is truly what we get. Keep up this level of thoroughness in your future tests!
app/client/cypress/e2e/Regression/ClientSide/Git/GitSync/GitSyncedApps_spec.js (1)
Line range hint
411-427: Excellent Work on Enabling Previously Skipped TestIt's great to see that you've unskipped this test case by changing
it.skiptoit. This will ensure our test suite is comprehensive and all critical functionalities are being tested.app/client/cypress/e2e/Regression/ServerSide/GenerateCRUD/MySQL1_Spec.ts (1)
12-12: Excellent addition of 'propPane' importIncluding
propPaneensures that property pane functions used later in the code are accessible.
| //Till bug fixed | ||
| it("2. Validation of default displayed in Select widget based on row selected + Bug 12531", function () { | ||
| table.SelectTableRow(1); | ||
| agHelper.ReadSelectedDropDownValue().then(($selectedValue) => { | ||
| expect($selectedValue).to.eq("#2"); | ||
| }); | ||
|
|
||
| // table.SelectTableRow(0); | ||
| // agHelper.ReadSelectedDropDownValue().then(($selectedValue) => { | ||
| // expect($selectedValue).to.eq("#1"); | ||
| // }); | ||
| table.SelectTableRow(0); | ||
| agHelper.ReadSelectedDropDownValue().then(($selectedValue) => { | ||
| expect($selectedValue).to.eq("#1"); | ||
| }); | ||
|
|
||
| // table.SelectTableRow(2); | ||
| // agHelper.ReadSelectedDropDownValue().then(($selectedValue) => { | ||
| // expect($selectedValue).to.eq("Select option"); | ||
| // }); | ||
| table.SelectTableRow(2); | ||
| agHelper.ReadSelectedDropDownValue().then(($selectedValue) => { | ||
| expect($selectedValue).to.eq("Select option"); | ||
| }); | ||
|
|
||
| // //Change select value now - failing here! | ||
| // agHelper.SelectDropDown("#1"); | ||
| // agHelper.ReadSelectedDropDownValue().then(($selectedValue) => { | ||
| // expect($selectedValue).to.eq("#1"); | ||
| // }); | ||
| //Change select value now - failing here! | ||
| agHelper.SelectDropDown("#1"); | ||
| agHelper.ReadSelectedDropDownValue().then(($selectedValue) => { | ||
| expect($selectedValue).to.eq("#1"); | ||
| }); | ||
|
|
||
| // table.SelectTableRow(2, 0, false); //Deselecting here! | ||
| // agHelper.ReadSelectedDropDownValue().then(($selectedValue) => { | ||
| // expect($selectedValue).to.eq("Select option"); | ||
| // }); | ||
| // }); | ||
| table.SelectTableRow(2, 0, false); //Deselecting here! | ||
| agHelper.ReadSelectedDropDownValue().then(($selectedValue) => { | ||
| expect($selectedValue).to.eq("Select option"); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Class, let's review this test case together!
Excellent work on re-enabling this important test case! It's like bringing a sleeping student back to life in our classroom. However, there are a few areas where we can make our test even better. Let's go through them:
- Use constants for expected values:
Instead of using plain strings in our expect statements, let's create constants. This will make our test more maintainable and easier to read.
const SELECT_OPTION = "Select option";
const OPTION_1 = "#1";
const OPTION_2 = "#2";
// Then use these constants in your expect statements
expect($selectedValue).to.eq(SELECT_OPTION);- Add more descriptive comments:
Let's add some comments to explain what each step is doing. This will help future students (I mean, developers) understand our test better.
// Select row 1 and verify the dropdown value
table.SelectTableRow(1);
agHelper.ReadSelectedDropDownValue().then(($selectedValue) => {
expect($selectedValue).to.eq(OPTION_2);
});- Consider refactoring repetitive code:
We're using the same pattern of selecting a row and checking the dropdown value multiple times. We could create a helper function to make our test more DRY (Don't Repeat Yourself).
function selectRowAndVerifyDropdown(rowIndex: number, expectedValue: string) {
table.SelectTableRow(rowIndex);
agHelper.ReadSelectedDropDownValue().then(($selectedValue) => {
expect($selectedValue).to.eq(expectedValue);
});
}
// Then use it like this:
selectRowAndVerifyDropdown(1, OPTION_2);
selectRowAndVerifyDropdown(0, OPTION_1);
selectRowAndVerifyDropdown(2, SELECT_OPTION);These changes will make our test case cleaner, more readable, and easier to maintain. Remember, clean code is happy code!
Would you like me to provide a fully refactored version of this test case?
| @@ -190,7 +190,7 @@ describe( | |||
| }); | |||
|
|
|||
| // https://github.com/appsmithorg/appsmith/issues/29870 Once this issue is fixed then this test case should be enabled and fixed for the table v2 | |||
| it.skip("7. Verify Refresh table from Deploy page - on Stores & verify all updates persists : Skipped till #29870 gets fixed", () => { | |||
| it("7. Verify Refresh table from Deploy page - on Stores & verify all updates persists : Skipped till #29870 gets fixed", () => { | |||
There was a problem hiding this comment.
💡 Codebase verification
Please keep the test skipped until issue #29870 is resolved.
Activating the test while the related issue is still open may lead to false negatives and unreliable test results. Once the issue is closed, you can consider enabling the test to ensure it functions as expected.
🔗 Analysis chain
Class, let's examine this change carefully.
The test case that was previously skipped has now been activated. This is a positive step towards improving our test coverage. However, we need to ensure that the issue mentioned in the comment (#29870) has indeed been resolved.
To verify if the issue has been resolved, let's run the following script:
If the issue is closed, we can proceed with confidence. If it's still open, we should consider whether it's appropriate to run this test or if we need to make any adjustments.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if issue #29870 has been closed
gh issue view 29870 --json state -q .state
Length of output: 49
| propPane.ChangeJsonFormFieldType( | ||
| "Text Description", | ||
| "Multiline Text Input", | ||
| ); | ||
| propPane.NavigateBackToPropertyPane(); | ||
| propPane.ChangeJsonFormFieldType( | ||
| "Html Description", | ||
| "Multiline Text Input", | ||
| ); |
There was a problem hiding this comment.
Replace plain strings with locator variables for better maintainability
To adhere to best practices, please use locator variables instead of plain strings when specifying field names and button labels. This applies to methods like ChangeJsonFormFieldType, EnterJSONTextAreaValue, and ClickButton. Using locator variables enhances readability and makes the code more robust to changes.
For example, you might define locator variables such as this.locators.textDescriptionField and this.locators.updateButton and use them in your methods:
- propPane.ChangeJsonFormFieldType(
- "Text Description",
- "Multiline Text Input",
- );
+ propPane.ChangeJsonFormFieldType(
+ this.locators.textDescriptionField,
+ "Multiline Text Input",
+ );
...
- agHelper.ClickButton("Update");
+ agHelper.ClickButton(this.locators.updateButton);Also applies to: 245-249
| table.ReadTableRowColumnData(3, 2, "v1", 200).then(($cellData) => { | ||
| expect($cellData).to.eq( | ||
| "The largest cruise ship is twice the length of the Washington Monument. Some cruise ships have virtual balconies.", | ||
| ); | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Avoid hardcoding strings in assertions
It's advisable to store expected values in variables when performing assertions with long strings. This improves clarity and makes future modifications easier.
Here's how you can refactor the assertion:
- expect($cellData).to.eq(
- "The largest cruise ship is twice the length of the Washington Monument. Some cruise ships have virtual balconies.",
- );
+ const expectedDescription = "The largest cruise ship is twice the length of the Washington Monument. Some cruise ships have virtual balconies.";
+ expect($cellData).to.eq(expectedDescription);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| table.ReadTableRowColumnData(3, 2, "v1", 200).then(($cellData) => { | |
| expect($cellData).to.eq( | |
| "The largest cruise ship is twice the length of the Washington Monument. Some cruise ships have virtual balconies.", | |
| ); | |
| }); | |
| table.ReadTableRowColumnData(3, 2, "v1", 200).then(($cellData) => { | |
| const expectedDescription = "The largest cruise ship is twice the length of the Washington Monument. Some cruise ships have virtual balconies."; | |
| expect($cellData).to.eq(expectedDescription); | |
| }); |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (32)
app/client/cypress/e2e/Regression/ClientSide/ActionExecution/ActionSelectorCreateShouldBind_spec.ts (3)
Line range hint
15-30: Class, let's review this test case and make some improvements!Good job on enabling this test by removing the
.skip. However, we need to make a few adjustments to align with our best practices:
- Avoid using
cy.wait(). Instead, use Cypress's built-in retry-ability and assertions.- Replace string selectors with data-* attributes or locator variables.
- Remove hardcoded wait strings.
Let's refactor this test case. Here's an example of how we can improve it:
it("binds newly created query / api to the button onClick", () => { entityExplorer.DragDropWidgetNVerify(draggableWidgets.BUTTON); propPane.SelectPlatformFunction("onClick", "Execute a query"); // Use data-* attribute instead of class selector agHelper.GetNClick("[data-cy=create-datasources-query-btn]"); // Use data-* attribute and wait for element to be visible cy.get("[data-cy=new-blank-api]").first().should('be.visible').click(); // Wait for the API creation to complete using an assertion cy.get("@createNewApi").should("have.property", "status", 201); EditorNavigation.CloseAnnouncementModal(); EditorNavigation.SelectEntityByName("Button1", EntityType.Widget); agHelper.GetNAssertElementText( propPane._actionCard, "GETExecute a queryApi1.run", ); entityExplorer.DeleteWidgetFromEntityExplorer("Button1"); });Remember, class, always strive for clean and efficient code!
Line range hint
32-46: Now, let's turn our attention to the second test case, students!While this test case is doing a good job of testing the JS object binding, we can make it even better by following our coding guidelines. Here are the areas we need to improve:
- Remove the use of
cy.wait().- Replace string selectors with data-* attributes or locator variables.
Let's refactor this test case to make it shine:
it("binds newly created JSObject to the button onClick", () => { entityExplorer.DragDropWidgetNVerify(draggableWidgets.BUTTON); propPane.SelectPlatformFunction("onClick", "Execute a JS function"); // Use data-* attribute instead of class selector agHelper.GetNClick("[data-cy=create-js-object-btn]"); // Wait for the JS collection creation to complete using an assertion cy.get("@createNewJSCollection").should("have.property", "status", 201); EditorNavigation.CloseAnnouncementModal(); EditorNavigation.SelectEntityByName("Button1", EntityType.Widget); agHelper.GetNAssertElementText( propPane._actionCard, "Execute a JS functionJSObject1.Button1onClick()", ); });By making these changes, we're ensuring our tests are more robust and follow best practices. Remember, clean code leads to reliable tests!
Line range hint
1-48: Alright, class, let's look at the big picture of our test file!Overall, you've done a good job structuring your tests. However, there's always room for improvement. Here are some suggestions to make your test file even better:
Consider extracting common steps into helper functions to reduce duplication. For example:
function setupButtonAndOpenActionSelector(action: string) { entityExplorer.DragDropWidgetNVerify(draggableWidgets.BUTTON); propPane.SelectPlatformFunction("onClick", action); }Add comments to explain the purpose of each test case. This will help future readers understand the intent behind each test.
Consider using
beforeorbeforeEachhooks to set up common test conditions, if applicable.Use constants for repeated string values to improve maintainability.
Consider adding more assertions to thoroughly verify the expected outcomes.
Here's an example of how you might structure your tests with these improvements:
import { ... } from "../../../../support/Objects/ObjectsCore"; import EditorNavigation, { ... } from "../../../../support/Pages/EditorNavigation"; describe("Creations via action selector should bind to the property", { tags: ["@tag.JS", "@tag.PropertyPane"] }, () => { const BUTTON_NAME = "Button1"; function setupButtonAndOpenActionSelector(action: string) { entityExplorer.DragDropWidgetNVerify(draggableWidgets.BUTTON); propPane.SelectPlatformFunction("onClick", action); } afterEach(() => { entityExplorer.DeleteWidgetFromEntityExplorer(BUTTON_NAME); }); // Test case for binding newly created query/API it("binds newly created query / api to the button onClick", () => { // ... (refactored test case 1) }); // Test case for binding newly created JS object it("binds newly created JSObject to the button onClick", () => { // ... (refactored test case 2) }); });Remember, clear and well-structured tests make our codebase more maintainable and easier to understand. Keep up the good work, class!
app/client/cypress/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker_With_Switch_spec.js (3)
Line range hint
31-52: Class, let's improve our test case!Good job on reactivating this test case! However, we can make it even better by following our best practices more closely. Let's work on these improvements:
Instead of using CSS selectors, let's use data-* attributes for our selectors. For example, replace
widgetsPage.switchWidgetwith a data attribute selector.We should remove the
cy.log(nextDay)statement to keep our test code clean and focused.To make our test more reliable, let's replace
cy.get(widgetsPage.switchWidget).click()with a more robust interaction method.Here's how we can refactor part of the test:
cy.get('[data-cy="switch-widget"]').click({ force: true }); cy.get('[data-cy="toast-message"]') .last() .invoke('text') .then((text) => { expect(text.trim()).to.equal(toasttext.trim()); }); cy.get('[data-cy="switch-widget-inactive"]').should('be.visible');Remember, clear and reliable tests make for happy developers!
Line range hint
54-67: Let's polish our test case, students!Excellent work on bringing this test case back to life! Now, let's make it shine by addressing a few areas:
We should use data-* attributes for our selectors instead of CSS selectors. This will make our tests more robust and easier to maintain.
To improve reliability, let's use a more robust method for clicking the datepicker input.
Our assertion is using a string, which we want to avoid. Let's refactor this to use a variable or constant.
Here's a suggested refactor:
const expectedToastMessage = 'Your expected message here'; cy.get('[data-cy="datepicker-input"]').click({ force: true }); cy.SetDateToToday(); cy.get('[data-cy="switch-widget-active"]').should('be.visible'); cy.get('[data-cy="toast-action"]') .last() .invoke('text') .then((text) => { expect(text.trim()).to.equal(expectedToastMessage); });Remember, clear and consistent tests make debugging a breeze!
Line range hint
1-72: Class, let's summarize our lesson!Great job on reactivating these important test cases! This will certainly improve our test coverage. However, we've identified some common areas for improvement across both tests:
- Consistently use data-* attributes for selectors instead of CSS selectors.
- Avoid using
cy.log()statements in our test code.- Use more robust methods for interacting with elements, like
{ force: true }option for clicks.- Refactor string-based assertions to use variables or constants.
By addressing these points, we'll create more reliable and maintainable tests. Remember, good tests are the foundation of a stable application!
Don't forget to apply these improvements to other test cases in the file as well. Keep up the good work, and happy testing!
app/client/cypress/e2e/Regression/ClientSide/Binding/SelectWidget_Spec.ts (1)
49-76: Class, let's review this new test case together!Good job on re-enabling this test case! It's important to test all scenarios, even those related to known bugs. However, I have a few suggestions to make this test even better:
The comment "Till bug fixed" on line 49 could be more informative. Let's elaborate on what the bug is about.
Add more descriptive comments throughout the test to explain the purpose of each step. This will help your fellow students understand the test better.
Consider replacing hardcoded values like "Give appropriate error when method is invalid in cURL command #1", "Fix embedded datasource path #2" with constants. This will make the test more maintainable in the long run.
Here's an example of how you could improve the first part of the test:
// Constants for dropdown options const OPTION_1 = "#1"; const OPTION_2 = "#2"; const SELECT_OPTION = "Select option"; // Test case for validating Select widget behavior with table row selection it("2. Validation of default displayed in Select widget based on row selected + Bug 12531", function () { // Select the second row and verify the dropdown value table.SelectTableRow(1); agHelper.ReadSelectedDropDownValue().then(($selectedValue) => { expect($selectedValue).to.eq(OPTION_2); }); // Select the first row and verify the dropdown value table.SelectTableRow(0); agHelper.ReadSelectedDropDownValue().then(($selectedValue) => { expect($selectedValue).to.eq(OPTION_1); }); // ... continue with the rest of the test ... });These changes will make your test more readable and easier to maintain. Keep up the good work!
app/client/cypress/e2e/Regression/ClientSide/BugTests/DatasourceSchema_spec.ts (1)
Line range hint
51-65: Class, let's discuss the use ofagHelper.Sleep(1500)in our test.Now, children, we've talked about this before. Using
agHelper.Sleep()is like taking a nap during a test - it's not very productive! Instead of sleeping, we should be actively waiting for something to happen. Can anyone suggest a better way to do this?Let's improve our test by replacing the
agHelper.Sleep(1500)with a more appropriate waiting mechanism. Here's a homework assignment for you:- agHelper.Sleep(1500); + agHelper.WaitUntilAllApiFinish();This way, we're waiting for a specific condition rather than just twiddling our thumbs for a set amount of time. Remember, in testing as in life, patience and attentiveness are virtues!
app/client/cypress/e2e/Regression/ClientSide/Binding/DatePicker_Text_spec.js (5)
Line range hint
17-52: Class, let's improve our test case implementation!I'm glad to see you've enabled this test case. However, there are a few areas where we can make it even better:
- Avoid using
cy.wait(). Instead, use Cypress's built-in retry-ability and assertions to wait for elements or states.- Use data-* attributes for selectors instead of plain strings or CSS selectors.
- Define locator variables for selectors to improve maintainability.
Let's refactor this part of the code:
cy.wait("@updateLayout"); cy.wait("@updateLayout");Replace it with appropriate assertions or commands that wait for the specific condition you're expecting after the layout update.
Also, let's improve our selector usage. For example:
cy.get(publishPage.datepickerWidget + commonlocators.inputField)Should be replaced with a data attribute selector and stored in a variable:
const datepickerInput = '[data-cy="datepicker-input"]'; cy.get(datepickerInput)Remember, clear and consistent selectors make our tests more robust and easier to maintain. Keep up the good work, and let's strive for excellence in our test implementations!
Line range hint
54-90: Let's enhance our selector strategy, class!I'm pleased to see this test case is now active. However, we have an opportunity to improve our code quality:
- Replace plain string selectors with data-* attributes.
- Use locator variables for selectors to enhance readability and maintainability.
For instance, let's refactor this selector:
cy.get(formWidgetsPage.datepickerWidget + " .bp3-input")We can improve it like this:
const datepickerInput = '[data-cy="datepicker-input"]'; cy.get(datepickerInput)Similarly, update other selectors in this test case. Remember, using consistent and meaningful selectors makes our tests more robust and easier to maintain.
Keep up the good work, and let's continue to refine our testing practices!
Line range hint
92-104: Time to polish our selector approach, students!It's great to see this test case activated. However, we can further improve our code quality:
- Replace plain string selectors with data-* attributes.
- Implement locator variables for selectors to boost readability and maintainability.
Let's refactor this selector:
cy.get(formWidgetsPage.datepickerWidget + commonlocators.inputField)We can enhance it like this:
const datepicker2Input = '[data-cy="datepicker2-input"]'; cy.get(datepicker2Input)Apply similar improvements to other selectors in this test case. Remember, consistent and meaningful selectors are the foundation of robust and maintainable tests.
Keep refining your skills, and let's strive for excellence in our testing practices!
Line range hint
127-152: Let's elevate our selector game, class!I'm delighted to see this test case now active. However, we have room for improvement in our code quality:
- Transition from plain string selectors to data-* attributes.
- Implement locator variables for selectors to enhance readability and maintainability.
For example, let's refactor this selector:
cy.get(formWidgetsPage.datepickerWidget)We can improve it like this:
const datepickerWidget = '[data-cy="datepicker-widget"]'; cy.get(datepickerWidget)Apply similar enhancements to other selectors in this test case. Remember, clear and consistent selectors are crucial for creating robust and maintainable tests.
Keep up the excellent work, and let's continue to refine our testing practices!
Line range hint
1-159: Class, let's review our overall test suite structure!I'm impressed with the logical flow of our test cases. However, there are a few areas where we can enhance our test suite:
Remove the empty afterEach hook at the end of the file. If it's not being used, it's best to keep our code clean and remove unnecessary elements.
Consistently replace cy.wait() calls with more robust waiting strategies throughout the file. Remember, Cypress has built-in retry-ability that we should leverage.
Create a constants file to store all our selectors. This will make it easier to maintain and update selectors across all our test files.
Consider using Cypress custom commands for repetitive actions like setting dates or clearing date pickers. This will make our tests more readable and maintainable.
Here's an example of how we could structure our constants file:
// constants.js export const SELECTORS = { DATEPICKER_INPUT: '[data-cy="datepicker-input"]', DATEPICKER_WIDGET: '[data-cy="datepicker-widget"]', // ... other selectors };Then in our test file:
import { SELECTORS } from '../constants'; // ... in our tests cy.get(SELECTORS.DATEPICKER_INPUT).click();Remember, clear structure and consistent practices make our test suite more robust and easier to maintain. Keep up the great work, and let's strive for excellence in our testing!
app/client/cypress/e2e/Regression/ClientSide/Autocomplete/JS_AC2_spec.ts (1)
Line range hint
114-185: Good job on unskipping and implementing this test case, class! Let's review it together.I'm pleased to see that you've followed many of our best practices:
- You've used custom commands like jsEditor and agHelper.
- You've avoided cy.wait, cy.pause, and agHelper.sleep().
- You're using data-* attributes for selectors.
- You've steered clear of Xpaths and CSS paths.
- You're not using it.only, after, or afterEach hooks.
However, there's always room for improvement. Here are some suggestions to make your test even better:
Add more descriptive assertion messages. For example:
agHelper.AssertElementAbsence(locators._hints, "Autocomplete hints should not be present");Enhance your comments to be more informative. For instance:
// Test autocomplete behavior when typing inside a string agHelper.TypeText(locators._codeMirrorTextArea, `const x = "`);Consider grouping related assertions into describe blocks for better organization.
Keep up the good work, and remember: clear tests lead to a happy class!
app/client/cypress/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker2_spec.js (2)
Line range hint
22-52: Class, let's review this test case together!Good job activating this previously skipped test! However, there are a few areas where we can improve our code to make it even better:
Remember to use locator variables for all selectors. For example, replace
formWidgetsPage.datepickerWidget + " .bp3-input"with a meaningful variable name.We should perform logins via API with LoginFromAPI at the beginning of our test. This will make our test more efficient and reliable.
Don't forget to perform logout via API with LogOutviaAPI at the end of our test. This ensures a clean state for subsequent tests.
Let's use multiple assertions for our expect statements. This will give us more detailed feedback if a test fails.
Here's an example of how we can improve our assertions:
cy.get(formWidgetsPage.datepickerWidget + " .bp3-input").should((input) => { expect(input).to.contain.value(nextDay); expect(input).to.be.visible; expect(input).to.not.be.disabled; });Keep up the good work, and remember these points for future tests!
Line range hint
1-214: Let's take a look at our entire test suite, class!Great job on your DatePicker widget tests! Here are some observations and suggestions for the whole file:
Excellent work avoiding cy.wait, cy.pause, and agHelper.sleep(). Keep it up!
I noticed several commented-out test cases. Let's review these and decide if we should implement them or remove them. Keeping commented-out code can lead to confusion.
For all our active test cases, let's apply the same improvements we discussed earlier:
- Use locator variables for all selectors.
- Implement LoginFromAPI at the beginning of each test.
- Use LogOutviaAPI at the end of each test.
- Enhance our assertions with multiple checks.
Consider breaking down larger test cases into smaller, more focused ones. This will make our tests easier to maintain and debug.
Don't forget to add clear, descriptive comments explaining the purpose of each test case. This will help your classmates understand your code better!
Keep up the fantastic work, and remember: clean, well-organized tests make for happy developers!
app/client/cypress/e2e/Regression/ClientSide/Git/GitSync/SwitchBranches_spec.js (4)
Line range hint
178-230: Good job activating the previously skipped test, but let's improve it further!Class, I'm pleased to see that you've activated the previously skipped test case. This is a step in the right direction for improving our test coverage. However, there are a few areas where we can make this test even better:
- Instead of using class selectors like
.ads-v2-spinner, let's use data-* attributes. This will make our tests more resilient to UI changes. For example:cy.get('[data-cy="branch-list-item"]').contains(tempBranchRegex);
There's some commented-out code that we should remove to keep our test file clean and easy to read. Remember, clean code is happy code!
The error handling for the branch switching operation could be more robust. Instead of just checking for the error message, let's assert that the correct error toast is displayed and that the application state remains consistent after the failed operation.
The
cy.wait(4000)is a fixed wait time, which can lead to flaky tests. Let's replace it with a more reliable wait strategy, such as waiting for a specific element to appear or disappear.Keep up the good work, and let's make these improvements to earn that A+!
Line range hint
232-248: A new test case! Let's make it shine even brighter!Well done on adding a new test case to verify branch switching behavior after creating a new page. This is an important scenario to cover. However, let's polish it up a bit:
- The
cy.wait(4000)is like waiting for the bell to ring - it's not very precise! Instead, let's wait for something specific to happen. For example:cy.get('[data-cy="page-loaded"]').should('be.visible');
- We're using class selectors like
.t--canvas-artboard. Remember our lesson on using data attributes? Let's update these to make our tests more robust:cy.get('[data-cy="canvas-artboard"]').should('be.visible');
To really make sure no errors occurred during the branch switch, let's add some more specific assertions. For example, check that no error toasts are displayed and that the new page is correctly loaded in the new branch.
The
agHelper.RefreshPage()at the end of the test might reset the application state. Consider if this is necessary or if it might interfere with subsequent tests.Keep refining your work, and soon you'll be at the top of the class!
Line range hint
250-293: A thorough test for branch list search - excellent effort!I'm impressed by the comprehensive coverage of search scenarios in this new test case. You've done a great job considering different search patterns. However, let's make a few adjustments to bring this test to the head of the class:
- We're still using class selectors like
.ads-v2-spinner. Let's update these to data attributes for better test stability:cy.get('[data-cy="spinner"]').should('not.exist');
- The
cy.wait(400)is like a quick nap during class - not very productive! Instead, let's wait for a specific condition:cy.get('[data-cy="branch-list-item"]').should('be.visible');
- I notice we're repeating some string values like 'branchListItem'. Let's create constants for these at the top of our file:
const SELECTORS = { BRANCH_LIST_ITEM: '[data-cy="branch-list-item"]', BRANCH_SEARCH_INPUT: '[data-cy="branch-search-input"]', // ... other selectors };Then use them in our tests:
cy.get(SELECTORS.BRANCH_LIST_ITEM).contains(childBKey);
- For the search scenarios, consider adding assertions to verify the number of results returned. This will make our tests even more robust.
Keep up this level of detail in your tests, and you'll be setting the curve for the whole class!
Line range hint
1-300: Overall assessment: Good progress, but room for improvement!Class, I'm pleased with the effort you've put into expanding our test coverage for Git synchronization functionality. The activation of previously skipped tests and the addition of new test cases show a commitment to improving our quality assurance.
However, remember that in testing, as in life, it's not just about what we do, but how we do it. Here are some general points to keep in mind for future improvements:
- Consistently use data-* attributes for selectors instead of class names or other less stable selectors.
- Replace fixed wait times (cy.wait) with more reliable wait strategies that depend on the application's state.
- Use constants for repeated string values to improve maintainability.
- Add more specific assertions to verify the absence of errors and the correct application state after operations.
- Keep your code clean by removing commented-out code and ensuring consistent formatting.
By focusing on these areas, we can make our tests not just more comprehensive, but also more robust and maintainable. Remember, in the world of testing, we're aiming for an A+, not just a passing grade!
Keep up the good work, and I look forward to seeing even better tests in your next assignment!
app/client/cypress/e2e/Regression/ClientSide/Widgets/Multiselect/MultiSelect5_spec.ts (1)
Line range hint
312-359: Good job on re-enabling the test case, but let's improve it further!Class, I'm pleased to see that you've re-enabled this important test case. You've done well in several areas:
- You're using
agHelper.VerifyEvaluatedErrorMessage()to check for error messages. That's the right way to do it!- Including a page refresh is a smart move to ensure the error persists. Well done!
- You're using
propPane.UpdatePropertyFieldValue()to update widget properties. That's the correct approach!- I'm happy to see you're not using
cy.wait,cy.pause, oragHelper.sleep(). Keep it up!- Avoiding
it.onlyis the right choice for our test suite.- Not using
afterorafterEachfollows our guidelines perfectly.- Using multiple assertions is a great practice. Good job!
However, there's always room for improvement. Let's work on these areas:
- Use locator variables for selectors instead of string selectors. This will make our tests more maintainable.
- Try to use data-* attributes for selectors where possible. It's a more robust approach.
- Consider performing login via API with LoginFromAPI at the beginning of the test if authentication is required.
Keep up the good work, and let's make these improvements to make our test even better!
app/client/cypress/e2e/Regression/ServerSide/GenerateCRUD/MySQL2_Spec.ts (4)
Line range hint
193-236: Good job on implementing the previously skipped test case, class!I'm pleased to see that you've added this important test for verifying the refresh functionality and persistence of updates. Your use of assertions and table navigation is commendable. However, let's make a small improvement to enhance readability:
Consider adding a brief comment explaining the purpose of the
agHelper.Sleep(3000)calls. For example:table.NavigateToNextPage(true, "v2"); //page 2 -agHelper.Sleep(3000); //wait for table navigation to take effect! +agHelper.Sleep(3000); // Allow time for table navigation and data loading table.WaitUntilTableLoad(0, 0, "v2"); //page 2This will help other developers understand the reasoning behind the sleep duration.
Line range hint
449-495: Excellent work on updating theGenerateCRUDNValidateDeployPagefunction, students!Your modifications to accommodate table v2 are well-implemented. The assertions for table data and JSON form validation are thorough and follow best practices. To further improve the function, consider this suggestion:
Extract the table data assertions into a separate helper function to improve readability and reusability. For example:
function assertTableData(row: number, expectedData: string[]) { expectedData.forEach((data, index) => { table.ReadTableRowColumnData(row, index, "v2", 200).then(($cellData) => { expect($cellData).to.eq(data); }); }); } // Usage in the function assertTableData(0, [col1Text, col2Text, col3Text]);This refactoring will make the function more concise and easier to maintain.
Line range hint
524-545: Well done on updating theupdateNVerifyfunction, class!Your modifications to accommodate table v2 are appropriate, and the added comment about row highlighting is helpful. The use of network request assertions is a good practice. To further enhance this function, consider the following suggestion:
Implement a retry mechanism for the table data assertion to improve test stability. Here's an example:
function assertTableDataWithRetry(rowIndex: number, colIndex: number, expectedData: string, maxRetries = 3) { let retries = 0; function attempt() { if (retries >= maxRetries) { throw new Error(`Failed to assert table data after ${maxRetries} attempts`); } table.ReadTableRowColumnData(rowIndex, colIndex, "v2", 200).then(($cellData) => { try { expect($cellData).to.eq(expectedData); } catch (error) { retries++; cy.wait(1000); // Wait before retrying attempt(); } }); } attempt(); } // Usage in the function assertTableDataWithRetry(rowIndex, colIndex, expectedTableData);This improvement will make the test more resilient to slight delays in data updates.
Line range hint
547-565: Great job on theupdatingStoreJSONPropertyFiledsfunction, students!Your implementation of updating JSON form field types and properties is consistent and well-structured. The use of the
propPaneobject for interactions is appropriate. To further improve this function, consider the following suggestion:Create a helper function to reduce repetition in the property updates. For example:
function updateFieldTypeAndNavigateBack(fieldName: string, newType: string) { propPane.ChangeJsonFormFieldType(fieldName, newType); propPane.NavigateBackToPropertyPane(); } function updatingStoreJSONPropertyFileds() { updateFieldTypeAndNavigateBack("Store Status", "Radio Group"); propPane.UpdatePropertyFieldValue( "Options", `[{ "label": "Active", "value": "A" }, { "label": "Inactive", "value": "I" }]` ); updateFieldTypeAndNavigateBack("Store Address", "Multiline Text Input"); updateFieldTypeAndNavigateBack("Store Secret Code", "Password Input"); }This refactoring will make the function more concise and easier to maintain. Remember, class, that DRY (Don't Repeat Yourself) is an important principle in programming!
app/client/cypress/e2e/Sanity/Datasources/MsSQL_Basic_Spec.ts (1)
Line range hint
154-254: Well done on activating this comprehensive test case, class!I'm pleased to see such a thorough examination of the one-click binding functionality. You've covered all the important aspects, from creating the widget to performing CRUD operations. Good job on using assertion helpers and waiting for network requests!
However, let's look at a few areas where we can improve:
Instead of using
agHelper.Sleep(), consider using more reliable waiting mechanisms. For example, you could wait for specific elements to be visible or for network requests to complete. This will make your tests more robust and less prone to timing issues.I noticed some magic numbers in your code, like
450and200for widget positioning. Let's extract these as constants at the top of your test file. This will make your code more maintainable and easier to understand.This test case is quite long and covers multiple aspects of functionality. Consider breaking it down into smaller, more focused test cases. For example, you could have separate tests for adding a row, editing a row, and searching.
Remember, class, smaller, focused tests are easier to maintain and debug!
app/client/cypress/e2e/Regression/ClientSide/Widgets/Tab/Tabs_2_spec.ts (2)
Line range hint
238-240: Let's avoid using CSS selectors with:containsfor better maintainabilityIn your code at lines 238-240:
agHelper.GetNClick( `${propPane._segmentedControl("0")}:contains('Large')`, );Using the
:containspseudo-class in CSS selectors can lead to brittle tests, as it's dependent on the exact text and might break if the text changes. Instead, I'd encourage you to use data-* attributes or predefined locator variables. This not only adheres to our coding guidelines but also makes your tests more robust.To fix this, consider identifying the element with a unique data-* attribute or modify the helper method to accept an argument that can be used to locate the element without relying on
:contains.
Line range hint
234-234: Using constants or variables instead of hardcoded strings enhances readabilityAt line 234:
agHelper.GetNClick(propPane._segmentedControl("0px"));You're passing
"0px"as a hardcoded string. Let's try to use a constant or a locator variable here. This practice improves readability and maintainability, especially if the value"0px"is used in multiple places or might change in the future.app/client/cypress/e2e/Regression/ServerSide/GenerateCRUD/MySQL1_Spec.ts (2)
249-249: Update the comment to reflect the current test objectiveThe comment
//Update does not work, Bug 14063suggests that the update functionality is not working due to Bug 14063. Since this test is verifying that the bug has been fixed, it's important to update the comment to reflect this.Here's the suggested change:
-agHelper.ClickButton("Update"); //Update does not work, Bug 14063 +agHelper.ClickButton("Update"); //Validating that Update works after fix for Bug 14063
262-264: Incomplete test case detectedI notice that the test case for verifying add/update/delete operations on new records is currently incomplete, with a placeholder comment
//To script aft bug fix!. It's important to either implement the test or temporarily skip it to maintain the integrity of your test suite.Would you like assistance in scripting this test case now that the bug has been resolved? I'm happy to help flesh out the test steps to ensure comprehensive coverage.
app/client/cypress/e2e/Regression/ClientSide/Git/GitSync/GitSyncedApps_spec.js (2)
Line range hint
428-436: Replace CSS selectors with data attributes for stabilityI notice you've used CSS class selectors like
.t--import-json-cardand.t--entity-itemin your test code. To make your tests more robust and less prone to breakage due to style changes, it's advisable to usedata-*attributes for selectors.Let's update your selectors to use
data-testidattributes. Here's how you can modify your code:- cy.get(".t--import-json-card").next().click(); + cy.get("[data-testid='import-json-card']").next().click(); - cy.get(".t--entity-item").eq(1).contains("crudpage_1"); + cy.get("[data-testid='entity-item']").eq(1).contains("crudpage_1");Please ensure that the relevant elements in the application have the appropriate
data-testidattributes assigned.
Line range hint
440-443: Avoid using 'after' hooks in test casesIt's great that you're performing cleanup, but according to our coding guidelines, we should avoid using
afterandafterEachhooks in our test cases. Instead, consider integrating the cleanup steps within your test functions or creating a dedicated test for cleanup.You can modify your code by moving the cleanup logic into the last test case, like this:
it("11. Import app from git and verify page order should not change", () => { // ... existing test code ... + // Clean up the test GitHub repository + gitSync.DeleteTestGithubRepo(repoName); });This approach keeps your tests self-contained and maintains clarity.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (15)
- app/client/cypress/e2e/Regression/ClientSide/ActionExecution/ActionSelectorCreateShouldBind_spec.ts (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Autocomplete/JS_AC2_spec.ts (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Binding/DatePicker_Text_spec.js (4 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Binding/SelectWidget_Spec.ts (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/BugTests/DatasourceSchema_spec.ts (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Git/GitSync/GitSyncedApps_spec.js (2 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Git/GitSync/SwitchBranches_spec.js (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker2_spec.js (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker_With_Switch_spec.js (2 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Widgets/Multiselect/MultiSelect5_spec.ts (1 hunks)
- app/client/cypress/e2e/Regression/ClientSide/Widgets/Tab/Tabs_2_spec.ts (1 hunks)
- app/client/cypress/e2e/Regression/ServerSide/GenerateCRUD/MySQL1_Spec.ts (2 hunks)
- app/client/cypress/e2e/Regression/ServerSide/GenerateCRUD/MySQL2_Spec.ts (1 hunks)
- app/client/cypress/e2e/Sanity/Datasources/MsSQL_Basic_Spec.ts (1 hunks)
- app/client/cypress/limited-tests.txt (1 hunks)
🧰 Additional context used
📓 Path-based instructions (15)
app/client/cypress/e2e/Regression/ClientSide/ActionExecution/ActionSelectorCreateShouldBind_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/e2e/Regression/ClientSide/Autocomplete/JS_AC2_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/e2e/Regression/ClientSide/Binding/DatePicker_Text_spec.js (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/e2e/Regression/ClientSide/Binding/SelectWidget_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/e2e/Regression/ClientSide/BugTests/DatasourceSchema_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/e2e/Regression/ClientSide/Git/GitSync/GitSyncedApps_spec.js (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/e2e/Regression/ClientSide/Git/GitSync/SwitchBranches_spec.js (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/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker2_spec.js (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/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker_With_Switch_spec.js (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/e2e/Regression/ClientSide/Widgets/Multiselect/MultiSelect5_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/e2e/Regression/ClientSide/Widgets/Tab/Tabs_2_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/e2e/Regression/ServerSide/GenerateCRUD/MySQL1_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/e2e/Regression/ServerSide/GenerateCRUD/MySQL2_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/e2e/Sanity/Datasources/MsSQL_Basic_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 (3)
app/client/cypress/e2e/Regression/ClientSide/Widgets/Tab/Tabs_2_spec.ts (1)
Line range hint
192-247: Great job revitalizing the style verification test!It's wonderful to see that the test case for "Verify colors, borders and shadows" has been reactivated. By ensuring this test runs, we're maintaining high standards for our UI components. Keep up the good work!
app/client/cypress/e2e/Regression/ServerSide/GenerateCRUD/MySQL1_Spec.ts (1)
12-12: Good job importing 'propPane' moduleBy adding
'propPane'to your import statement, you ensure that all the property pane functions are available for your tests. This is essential for manipulating widget properties within your test cases.app/client/cypress/e2e/Regression/ClientSide/Git/GitSync/GitSyncedApps_spec.js (1)
Line range hint
411-427: Well done on restoring the test case functionalityYour effort to re-enable the test case is commendable. The test is correctly implemented and adheres to our best practices. This will enhance the reliability of our testing suite.
| cypress/e2e/Sanity/Datasources/MsSQL_Basic_Spec.ts | ||
| cypress/e2e/Regression/ClientSide/Autocomplete/JS_AC2_spec.ts | ||
| cypress/e2e/Regression/ClientSide/Binding/DatePicker_Text_spec.js | ||
| cypress/e2e/Regression/ClientSide/Binding/SelectWidget_Spec.ts | ||
| cypress/e2e/Regression/ClientSide/BugTests/DatasourceSchema_spec.ts | ||
| cypress/e2e/Regression/ClientSide/Git/GitSync/GitSyncedApps_spec.js | ||
| cypress/e2e/Regression/ClientSide/Git/GitSync/SwitchBranches_spec.js | ||
| cypress/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker_With_Switch_spec.js | ||
| cypress/e2e/Regression/ClientSide/Widgets/Datepicker/DatePicker2_spec.js | ||
| cypress/e2e/Regression/ClientSide/Widgets/Multiselect/MultiSelect5_spec.ts | ||
| cypress/e2e/Regression/ClientSide/Widgets/Tab/Tabs_2_spec.ts | ||
| cypress/e2e/Regression/ServerSide/GenerateCRUD/MySQL1_Spec.ts | ||
| cypress/e2e/Regression/ServerSide/GenerateCRUD/MySQL2_Spec.ts | ||
| cypress/e2e/Regression/ClientSide/ActionExecution/ActionSelectorCreateShouldBind_spec.ts |
There was a problem hiding this comment.
💡 Codebase verification
Attention Team: Missing Fork_Template_spec.js Test
It looks like the Fork_Template_spec.js test was removed from our limited test suite, and I couldn't find a direct replacement. This might mean we're missing crucial coverage for the template forking functionality.
Action Items:
- Verify Coverage: Check if other tests, such as those in
BuildingBlock.test.tsxorTemplateCard.test.tsx, adequately cover the template forking scenarios previously handled byFork_Template_spec.js. - Add Missing Tests: If coverage is lacking, reinstate the
Fork_Template_spec.jstest or create new tests to ensure comprehensive coverage of template forking features.
🔗 Analysis chain
Class, let's review the changes in our test suite!
Good morning, students! Today, we're going to examine the modifications made to our limited-tests.txt file. Let's break it down:
-
Test Coverage Expansion:
We've significantly increased our test coverage! We've gone from a single test to a whopping 14 tests. This is like going from a pop quiz to a full exam. It's more comprehensive and will give us a better understanding of our application's health. -
Removal of 'Fork_Template_spec.js':
Now, pay attention here. We've removed the 'Fork_Template_spec.js' test. Can anyone tell me why this might be important? That's right! We need to ensure that template forking functionality is still being tested elsewhere. Let's make a note to double-check this. -
File Format Consistency:
I'm pleased to see that everyone has maintained proper formatting. Each test specification is on its own line, just like how each answer should be on its own line in your exam papers. Well done! -
Purpose Reminder:
Remember, class, this file is crucial for our CI process. It's like our study guide for the big test. We use it to run a limited set of tests quickly. Always keep this purpose in mind when modifying this file.
Homework assignment: Let's verify if the 'Fork_Template_spec.js' test is covered elsewhere. Run this command:
Any volunteers to share their findings tomorrow?
Great effort, everyone! It seems our previous search didn't find the cypress/e2e directory. Let's broaden our search to ensure we locate any test files related to template forking. Please run the following command:
Alright class, our previous search didn’t find the cypress/e2e directory. Let’s broaden our search to ensure we locate any test files related to template forking across the entire repository. Please run the following command:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any test files related to template forking
rg -t js -t ts "Fork.*Template" "cypress/e2e"
Length of output: 97
Script:
# Search for any test files related to template forking across the entire repository
rg -t js -t ts "Fork.*Template"
Length of output: 8175
Script:
# Search for any test files related to template forking across the entire repository
rg -t js -t ts "Fork.*Template"
Length of output: 8175
| it("6. Verify Update/Delete row/Delete field data from Deploy page - on Productlines - existing record + Bug 14063", () => { | ||
| EditorNavigation.SelectEntityByName("update_form", EntityType.Widget); | ||
| propPane.ChangeJsonFormFieldType( | ||
| "Text Description", | ||
| "Multiline Text Input", | ||
| ); | ||
| propPane.NavigateBackToPropertyPane(); | ||
| propPane.ChangeJsonFormFieldType( | ||
| "Html Description", | ||
| "Multiline Text Input", | ||
| ); | ||
| propPane.NavigateBackToPropertyPane(); | ||
| deployMode.DeployApp(); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider using locator variables instead of plain strings for selectors
In your test steps where you change the JSON form field types, you're using plain strings like "Text Description" and "Multiline Text Input". While this works, it's best practice to use locator variables or data-* attributes for selectors. This enhances maintainability and reduces the risk of errors if the field names change.
To improve your code, you might define constants for these field names:
const FIELD_TEXT_DESCRIPTION = "Text Description";
const FIELD_MULTILINE_TEXT_INPUT = "Multiline Text Input";
propPane.ChangeJsonFormFieldType(FIELD_TEXT_DESCRIPTION, FIELD_MULTILINE_TEXT_INPUT);| deployMode.EnterJSONTextAreaValue( | ||
| "Html Description", | ||
| "The largest cruise ship is twice the length of the Washington Monument. Some cruise ships have virtual balconies.", | ||
| ); | ||
| agHelper.ClickButton("Update"); //Update does not work, Bug 14063 |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Use locator variables instead of plain strings when interacting with UI elements
In lines where you interact with UI elements, such as deployMode.EnterJSONTextAreaValue("Html Description", "...") and agHelper.ClickButton("Update");, you're using plain strings as selectors. It's advisable to use locator variables or data-* attributes for better reliability and readability.
Consider defining locator variables for these elements:
const FIELD_HTML_DESCRIPTION = "Html Description";
const BUTTON_UPDATE = locators._updateButton; // Assuming this locator exists
deployMode.EnterJSONTextAreaValue(FIELD_HTML_DESCRIPTION, "Your text here");
agHelper.ClickButton(BUTTON_UPDATE);
Executing skipped tests in CE
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Documentation