-
Notifications
You must be signed in to change notification settings - Fork 133
SWTBot test case: SDKconfig Editor #1123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
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 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. 📒 Files selected for processing (3)
WalkthroughThis pull request introduces a new test class, Changes
Possibly related PRs
Suggested reviewers
Poem
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
CodeRabbit Configuration File (
|
There was a problem hiding this 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:
- The content/format of the sdkconfig file
- Error cases (e.g., what happens if project creation fails)
- 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:
- Moving it to a separate utility class
- Making relevant methods public
- Adding proper documentation for each method
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 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
.../com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java
Show resolved
Hide resolved
.../com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java
Show resolved
Hide resolved
.../com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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 callsSystem.err.println, which can be replaced with a proper logger or the JUnitfailmethod 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.
TheSWTBotLabelimport 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
📒 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 staticbeforeTestClasssets 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.
Importingjava.util.regex.Patternis correct for robust console matching. Be mindful of performance overhead if used extremely frequently.
31-31: Partition table usage.
AddingSWTBotTableimport 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 withtable.rowCount() > 1to 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 2Length 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.
There was a problem hiding this 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.
Usingcontains(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.
SinceOperationResponseonly wraps a boolean, simplifying or inlining it might reduce complexity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 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.
There was a problem hiding this 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
waitWhileDialogIsVisibleandwaitForDialogToAppear. 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
📒 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.
There was a problem hiding this 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
📒 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
|
@kolipakakondal @alirana01 hi ! |
alirana01
left a comment
There was a problem hiding this 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
.../com/espressif/idf/ui/test/executable/cases/project/NewEspressifIDFProjectSDKconfigTest.java
Outdated
Show resolved
Hide resolved
281420d to
7357703
Compare
There was a problem hiding this 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
📒 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
7357703 to
697e2f5
Compare
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.
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
Summary by CodeRabbit
NewEspressifIDFProjectSDKconfigTestto validate project creation and configuration workflows.NewEspressifIDFProjectPartitionTableEditorTestto improve dialog visibility handling.TestWidgetWaitUtilitywith improved methods for synchronous management of UI operations and dialog visibility.