Skip to content

Conversation

@AndriiFilippov
Copy link
Collaborator

@AndriiFilippov AndriiFilippov commented Jan 21, 2025

Description

Please include a summary of the change and which issue is fixed.

Fixes # (IEP-XXX)

Type of change

Please delete options that are not relevant.

  • New feature (non-breaking change which adds functionality)

Tests:

І.
after project created with "reconfigure command" selected - verify SDKconfig is generated ✅
after project creation - open SDKconfig file using DoubleClick - verify basic content presents ✅
after project creation - open SDKconfig file using ESP-IDF Menu - verify basic content presents ✅
after project creation - open SDKconfig file - edit - save - close - reopen - verify changes are saved ✅
after project creation - delete SDKconfig file - rebuild - verify SDKconfig file is generated - verify basic content ✅

ІІ.
after project creation - open SDKconfig file - edit - save - close - build - reopen - verify changes are saved✅

ІІІ.
after project creation - open SDKconfig file - close - rebuild - check if it start the full re-build process ❗
This test is commented out until the old bug with the repeated project build is fixed.❗

Checklist

  • PR Self Reviewed
  • Applied Code formatting
  • Added Documentation
  • Added Unit Test
  • Verified on all platforms - Windows,Linux and macOS

Summary by CodeRabbit

  • Tests
    • Added a new test class for Espressif IDF project testing:
      • NewEspressifIDFProjectSDKconfigTest to validate project creation and configuration workflows.
    • Updated NewEspressifIDFProjectPartitionTableEditorTest to improve dialog visibility handling.
    • Enhanced test utility TestWidgetWaitUtility with improved methods for synchronous management of UI operations and dialog visibility.

@coderabbitai
Copy link

coderabbitai bot commented Jan 21, 2025

Warning

Rate limit exceeded

@AndriiFilippov has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 9 minutes and 3 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 7357703 and 697e2f5.

📒 Files selected for processing (3)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (4 hunks)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectPartitionTableEditorTest.java (1 hunks)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java (1 hunks)

Walkthrough

This pull request introduces a new test class, NewEspressifIDFProjectSDKconfigTest, to validate the creation and operations of Espressif IDF projects. It also updates the NewEspressifIDFProjectPartitionTableEditorTest class and enhances the TestWidgetWaitUtility class by replacing asynchronous methods with synchronous ones for better UI operation management. The changes improve the handling of dialog visibility and project lifecycle operations within the testing framework.

Changes

File Change Summary
tests/.../NewEspressifIDFProjectSDKconfigTest.java New test class for SDKconfig workflow testing
tests/.../NewEspressifIDFProjectPartitionTableEditorTest.java Updated dialog visibility handling in existing test class
tests/.../TestWidgetWaitUtility.java - Replaced async method with sync method for operations
- Added waitForDialogToAppear method
- Updated dialog visibility and SDK configuration tab methods

Possibly related PRs

Suggested reviewers

  • kolipakakondal
  • alirana01

Poem

🐰 A rabbit's tale of testing delight,
Where SDKconfig shines so bright!
Partition tables dance with glee,
UI widgets wait patiently,
Our code now robust and tight! 🧪


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

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

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

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

CodeRabbit Commands (Invoked using PR comments)

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

Other keywords and placeholders

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

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

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

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 3

🧹 Nitpick comments (4)
tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java (4)

1-4: Update the copyright year.

The copyright notice shows year 2025, which is in the future. Consider updating it to the current year.

-* Copyright 2025 Espressif Systems (Shanghai) PTE LTD. All rights reserved.
+* Copyright 2024 Espressif Systems (Shanghai) PTE LTD. All rights reserved.

53-60: Consider adding a timeout to prevent test hanging.

UI tests can sometimes hang due to various reasons (dialog not appearing, element not found, etc.). Consider adding a timeout to prevent the test from running indefinitely.

 @Test
+@org.junit.rules.Timeout(value = 300000) // 5 minutes
 public void givenNewProjectIsCreatedThenProjectContainsSDKconfigFile() throws Exception

53-60: Enhance test coverage with additional assertions.

The test verifies the presence of the sdkconfig file but doesn't validate:

  1. The content/format of the sdkconfig file
  2. Error cases (e.g., what happens if project creation fails)
  3. Project creation with different templates

Consider adding these test cases for more comprehensive coverage.


62-151: Consider making Fixture class reusable across test classes.

The Fixture class contains useful setup and verification methods that could be reused in other test classes. Consider:

  1. Moving it to a separate utility class
  2. Making relevant methods public
  3. Adding proper documentation for each method
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 04b99d1 and bb53cc5.

📒 Files selected for processing (1)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
  • GitHub Check: build
  • GitHub Check: build_macos

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (10)
tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/operations/EnvSetupOperations.java (1)

80-81: Consider verifying the tab’s presence and confirming the need to close it immediately.

You are activating and then immediately closing the "ESP-IDF Manager" tab. If that tab is necessary for subsequent actions or user interaction, closing it might be premature. Additionally, consider verifying that the tab item is present before attempting to activate it to avoid potential race conditions or errors if the tab is slow to appear.

tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectPartitionTableEditorTest.java (6)

25-30: Doc comment references “SBOM feature” instead of partition tables.
This doc comment seems inconsistent with the actual focus of the class, which is about Partition Table Editor testing. Consider updating it to reflect the class purpose accurately.

- * Test class to test the SBOM feature
+ * Test class to test the Partition Table Editor functionality

42-53: Use a more structured logging approach for exceptions.
The try-catch block calls System.err.println, which can be replaced with a proper logger or the JUnit fail method to ensure the error is captured in test logs.

- System.err.println("Error during cleanup: " + e.getMessage());
+ e.printStackTrace();
+ // Or use a logging framework:
+ logger.error("Error during cleanup", e);

55-64: Test readability.
Good arrangement of given/when/then steps. The test name “givenNewProjectCreatedNotBuiltWhenOpenEmptyPartitionTableEditorThenInformationPopUpMessage” is descriptive, although quite long. Consider adopting a consistent naming pattern to keep method names concise while remaining expressive.


78-88: Add row test coverage.
You are validating that one row is added, but consider including checks that confirm row content correctness, ensuring each column defaults to the expected initial values.


103-116: Save and quit logic.
The test ensures changes are saved upon quitting, which is good. However, consider adding more logs or assertions so that future maintainers know exactly which changes are confirmed.


134-243: Fixture class approach.
This class effectively encapsulates test preconditions and steps, promoting reuse. However, it might become quite large and harder to maintain. Consider splitting reused test actions into smaller utility classes if the code grows further.

tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/operations/ProjectTestOperations.java (3)

28-28: New label widget usage.
The SWTBotLabel import is introduced. Ensure that label scanning aligns with accessibility or user-facing text. Avoid coupling test logic to rapidly changing label text.


594-620: Hard-coded partition table expectations.
You’re checking the table content against a static array. This might break if the built-in table or columns evolve. Consider factoring these expectations out into a config file or making them more flexible to reduce maintenance overhead.


622-628: comparePartitionTableRows logic.
The approach of expecting an exact difference from the baseline is clear, but it can silently fail if the baseline changes. Suggest logging the actual vs. expected to facilitate debugging if an unexpected row count occurs.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bb53cc5 and a2a191c.

📒 Files selected for processing (6)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectPartitionTableEditorTest.java (1 hunks)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java (1 hunks)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectTest.java (2 hunks)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/operations/EnvSetupOperations.java (1 hunks)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/operations/ProjectTestOperations.java (5 hunks)
  • tests/pom.xml (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java
⏰ Context from checks skipped due to timeout of 90000ms (2)
  • GitHub Check: build_macos
  • GitHub Check: build
🔇 Additional comments (11)
tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectPartitionTableEditorTest.java (4)

34-35: Naming and readability check.
The class name and file name are aligned and descriptive. Good job avoiding redundant naming like “TestTest”.


36-41: Potential concurrency or environment loading concerns.
The static beforeTestClass sets up the environment once, which is typically fine. However, if these tests run concurrently with others or if the environment might be stale, consider re-initializing or verifying environment state in each test to guard against cross-test pollution.


66-76: Validate the necessity of building steps.
You build the project to ensure the partition table is generated properly. Double-check if any race conditions could occur (e.g., building in parallel with open editors). Possibly add a short wait or an assertion that the build completes before proceeding.


90-101: Error handling for row deletion.
In some cases, projects might not have any rows to delete (e.g., if the partition file fails to load). Verify that the test handles or logs such scenarios to avoid index-out-of-bounds errors.

tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectTest.java (2)

272-272: Check the “Install New Component” prompt for user flow clarity.
Invoking “Install New Component” directly is clear, but ensure the test environment is fully ready (e.g., build has completed, dependencies are recognized) before calling this command to avoid unpredictable results.


337-340: thenConsoleShowsBuildSuccessful method signature changed to throw IOException.
The updated signature is appropriate for console reading. Ensure all call sites handle or propagate the exception properly and that the test framework logs any resulting IO issues.

tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/operations/ProjectTestOperations.java (4)

12-12: Regex import usage.
Importing java.util.regex.Pattern is correct for robust console matching. Be mindful of performance overhead if used extremely frequently.


31-31: Partition table usage.
Adding SWTBotTable import suggests table interactions. Ensure you handle potential table refresh intervals, especially if partition table is large or updated asynchronously by the build process.


585-592: Check Shell Content method.
This method is straightforward. However, it might fail if the shell’s contents are changed or if multiple labels exist with the same text. Consider verifying a distinct label if the UI strings are not guaranteed unique.


630-636: deletePartitionTableRow method.
Selecting index 1 is fine when you know row 0 is “nvs,” but be sure the table always has enough rows. Possibly guard with table.rowCount() > 1 to avoid out-of-bounds if the test environment changes.

+ if (table.rowCount() > 1) {
    table.select(1);
    bot.toolbarButton("Delete Selected").click();
    bot.button("OK").click();
+ }
✅ Verification successful

Add guard condition to prevent out-of-bounds access in deletePartitionTableRow

The test class shows that while row deletion is a core operation that's expected to work, adding a guard condition is a safer approach that will prevent test failures if the partition table structure changes. The suggested change should be implemented.

🏁 Scripts executed

The following scripts were executed for the analysis:

Error: No shell scripts found


Script:

#!/bin/bash
# Search for usages of deletePartitionTableRow and partition table related code
rg -l "deletePartitionTableRow" --type java
rg "table.*nvs" --type java -B 2 -A 2
ast-grep --pattern 'public static void deletePartitionTableRow($$$)'

Length of output: 393


Script:

#!/bin/bash
# Check the test case file and look for partition table setup
cat tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectPartitionTableEditorTest.java

# Search for partition table initialization patterns
rg "new.*Table" --type java -B 2 -A 2
rg "createPartition" --type java -B 2 -A 2

Length of output: 66788

tests/pom.xml (1)

33-33: Increased memory usage.
Doubling heap space can improve test stability for resource-intensive UI tests, but might mask memory leaks or cause issues on machines with lower specs. Confirm the build environment can handle 8GB memory usage.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🔭 Outside diff range comments (1)
tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (1)

Consider reducing the extremely high timeout value
The current timeout of 99000000ms (~27.5 hours) is excessive for test scenarios. Consider reducing it to a more reasonable value (e.g., 5-10 minutes) or making it configurable. The job filtering logic that only ignores "refresh" operations is appropriate given the usage contexts.

🔗 Analysis chain

Line range hint 68-113: Consider clarifying or refining the job filtering logic and timeout value.
The method waits while any in-progress job that does not contain "refresh" remains active, which might be too narrow (only ignoring "Refreshing Projects"). Also, the timeout is extremely high (27+ hours). You may want to consider a shorter or configurable timeout to prevent lengthy test hangs.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verify usage patterns of waitForOperationsInProgressToFinishSync to see if it ever interacts with other job types.

ast-grep --pattern $'TestWidgetWaitUtility.waitForOperationsInProgressToFinishSync($_)'

Length of output: 1641


Script:

#!/bin/bash
# Check the context around the usage of waitForOperationsInProgressToFinishSync
for file in $(rg -l "waitForOperationsInProgressToFinishSync"); do
  echo "=== $file ==="
  rg -B 2 -A 2 "waitForOperationsInProgressToFinishSync" "$file"
done

# Look for similar wait utilities and timeout patterns
ast-grep --pattern 'waitWhile($_, $timeout, $_)'

Length of output: 4244

🧹 Nitpick comments (2)
tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (2)

Line range hint 235-266: Ensure that partial title matching is strictly intended.
Using contains(dialogTitle) can inadvertently catch similarly titled dialogs. If exact matching is desired, consider using equality instead. Otherwise, this partial match is perfectly fine for the typical usage scenario.


285-296: Consider inlining or simplifying OperationResponse.
Since OperationResponse only wraps a boolean, simplifying or inlining it might reduce complexity.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9f123b9 and f0c402b.

📒 Files selected for processing (2)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (4 hunks)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: build_macos
🔇 Additional comments (1)
tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (1)

268-284: Verify that isActive() is the intended behavior.
This method waits until the SDK Configuration tab is the active tab. If the requirement is only to confirm its availability, you may need to check for presence rather than activeness.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (2)
tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (2)

Line range hint 68-113: Consider reducing the excessive timeout value.

The timeout value of 99000000ms (>27 hours) seems unnecessarily long for UI operations. Consider reducing it to a more reasonable value, such as 5-10 minutes (300000-600000ms), to prevent tests from hanging indefinitely.

-		}, 99000000, 500);
+		}, 600000, 500);

272-290: Consider extracting common dialog visibility check logic.

The dialog visibility check logic is duplicated between waitWhileDialogIsVisible and waitForDialogToAppear. Consider extracting it into a private helper method.

+	private static boolean isDialogVisible(SWTWorkbenchBot workbenchBot, String dialogTitle) {
+		for (SWTBotShell shell : workbenchBot.shells()) {
+			if (shell.getText().contains(dialogTitle)) {
+				return true;
+			}
+		}
+		return false;
+	}
+
 	public static void waitWhileDialogIsVisible(SWTWorkbenchBot workbenchBot, String dialogTitle, long timeout)
 	{
 		workbenchBot.waitWhile(new DefaultCondition()
 		{
 			@Override
 			public boolean test() throws Exception
 			{
-				for (SWTBotShell shell : workbenchBot.shells())
-				{
-					if (shell.getText().contains(dialogTitle))
-					{
-						return true;
-					}
-				}
-				return false;
+				return isDialogVisible(workbenchBot, dialogTitle);
 			}
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f0c402b and b4c199f.

📒 Files selected for processing (2)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (4 hunks)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java
⏰ Context from checks skipped due to timeout of 90000ms (2)
  • GitHub Check: build
  • GitHub Check: build_macos
🔇 Additional comments (2)
tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (2)

236-259: LGTM! Well-implemented dialog visibility check.

The implementation correctly iterates through all shells and provides clear error messaging.


293-309: LGTM! Clean and straightforward tab activation check.

The implementation efficiently checks for the SDK Configuration tab's active state.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (4)
tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (4)

Line range hint 68-114: Optimize timeout value and approve sync implementation.

The synchronous implementation with job filtering is a good improvement over the async version. However, the timeout value of 99000000ms (27.5 hours) seems excessive for a UI operation.

Consider using a more reasonable timeout value, such as 5-10 minutes (300000-600000ms). For example:

-		}, 99000000, 500);
+		}, 300000, 500); // 5 minutes timeout

216-240: Consider handling quick dialog transitions.

The implementation correctly checks for dialog appearance. However, consider handling cases where the dialog might appear and disappear quickly.

Consider adding a check to ensure the shell is both visible and not disposed:

 for (SWTBotShell shell : workbenchBot.shells()) {
-    if (shell.getText().contains(dialogTitle)) {
+    if (shell.getText().contains(dialogTitle) && 
+        !shell.widget.isDisposed() && 
+        shell.isVisible()) {
         return true;
     }
 }

252-271: Apply consistent shell state checking.

For consistency with the suggested improvement in waitForDialogToAppear, apply the same shell state checking here.

Apply the same shell state checks:

 for (SWTBotShell shell : workbenchBot.shells()) {
-    if (shell.getText().contains(dialogTitle)) {
+    if (shell.getText().contains(dialogTitle) && 
+        !shell.widget.isDisposed() && 
+        shell.isVisible()) {
         return true;
     }
 }

273-290: Add existence check before checking active state.

The implementation correctly checks for the active state, but consider adding a check for tab existence to provide better error messages.

Consider enhancing the error handling:

 @Override
 public boolean test() throws Exception {
-    return workbenchBot.cTabItem("SDK Configuration (sdkconfig)").isActive();
+    try {
+        return workbenchBot.cTabItem("SDK Configuration (sdkconfig)").isActive();
+    } catch (WidgetNotFoundException e) {
+        return false;
+    }
 }

 @Override
 public String getFailureMessage() {
-    return "SDK Configuration tab did not open in time.";
+    return "SDK Configuration tab was not found or did not become active in time.";
 }
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fef8cb4 and f64cba9.

📒 Files selected for processing (2)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (4 hunks)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java
⏰ Context from checks skipped due to timeout of 90000ms (2)
  • GitHub Check: build
  • GitHub Check: build_macos

@AndriiFilippov
Copy link
Collaborator Author

@kolipakakondal @alirana01 hi !
Please, review

@AndriiFilippov AndriiFilippov changed the title WIP: SWTBot test case: SDKconfig Editor SWTBot test case: SDKconfig Editor Jan 31, 2025
Copy link
Collaborator

@alirana01 alirana01 left a comment

Choose a reason for hiding this comment

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

LGTM minor changes required can be merged after those and green builds

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (3)
tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (3)

Line range hint 68-113: LGTM! Consider adding Javadoc.

The synchronous implementation with job filtering is a good improvement over the async version. It will make tests more stable by avoiding race conditions.

Add Javadoc to document the job filtering behavior:

+/**
+ * Waits for all non-refresh operations to complete in the Progress view.
+ * Background refresh operations are filtered out to avoid false positives.
+ * 
+ * @param bot current SWTWorkbenchBot reference
+ */
 public static void waitForOperationsInProgressToFinishSync(SWTWorkbenchBot bot)

216-240: Consider adding a small delay between checks.

While the implementation is correct, continuous shell iteration might be CPU intensive. Adding a small delay between checks would reduce CPU usage without significantly impacting test speed.

 public static void waitForDialogToAppear(SWTWorkbenchBot workbenchBot, String dialogTitle, long timeout)
 {
-    workbenchBot.waitUntil(new DefaultCondition()
+    workbenchBot.waitUntil(new DefaultCondition()
     {
         @Override
         public boolean test() throws Exception
         {
+            try {
+                Thread.sleep(100); // Add small delay between checks
+            } catch (InterruptedException e) {
+                Thread.currentThread().interrupt();
+            }
             for (SWTBotShell shell : workbenchBot.shells())
             {
                 if (shell.getText().contains(dialogTitle))

273-290: Add error handling for missing tab.

The implementation should handle the case where the tab doesn't exist yet.

 public static void waitForSDKConfigurationTab(SWTWorkbenchBot workbenchBot, long timeout)
 {
     workbenchBot.waitUntil(new DefaultCondition()
     {
         @Override
         public boolean test() throws Exception
         {
-            return workbenchBot.cTabItem("SDK Configuration (sdkconfig)").isActive();
+            try {
+                return workbenchBot.cTabItem("SDK Configuration (sdkconfig)").isActive();
+            } catch (WidgetNotFoundException e) {
+                return false;
+            }
         }
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 281420d and 7357703.

📒 Files selected for processing (3)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (4 hunks)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectPartitionTableEditorTest.java (1 hunks)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: build_macos
🔇 Additional comments (3)
tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/common/utility/TestWidgetWaitUtility.java (1)

252-271: Apply the same delay optimization as waitForDialogToAppear.

The implementation is consistent with waitForDialogToAppear. Consider applying the same delay optimization here.

tests/com.espressif.idf.ui.test/src/com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectPartitionTableEditorTest.java (2)

174-174: LGTM! Correct usage of the new utility method.

The change to use waitForDialogToAppear is appropriate and consistent with the new implementation.


180-180: LGTM! Correct usage of the new utility method.

The change to use waitForDialogToAppear is appropriate and consistent with the new implementation.

added tests to open and verify sdkconfig file content
fixed UI focus conflict in waitWhileDialogIsVisible method
fixed focus conflict in waitUntilDialogIsNotVisible method
renamed waitUntilDialogIsNotVisible to waitForDialogToAppear
removed duplicate method
@AndriiFilippov AndriiFilippov merged commit e60d439 into master Feb 3, 2025
5 of 6 checks passed
@kolipakakondal kolipakakondal deleted the IEP-1407 branch February 18, 2025 06:20
@coderabbitai coderabbitai bot mentioned this pull request Sep 18, 2025
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants