-
Notifications
You must be signed in to change notification settings - Fork 3.6k
[quick_actions_ios] Migrate XCTest to Swift Testing #10767
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
base: main
Are you sure you want to change the base?
Conversation
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.
Code Review
This pull request migrates the iOS quick actions plugin tests from XCTest to the new Swift Testing framework. The changes involve updating the test file QuickActionsPluginTests.swift to use the new @Test macros, #expect assertions, and async testing features. The project's Swift version is also updated to 6.0 to support Swift Testing.
The migration is well-executed. I have one suggestion to improve the robustness of an asynchronous test to better align with the original test's logic and be less dependent on the mock's implementation details.
packages/quick_actions/quick_actions_ios/example/ios/RunnerTests/QuickActionsPluginTests.swift
Show resolved
Hide resolved
ae30d6a to
88d4558
Compare
|
/gemini review |
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.
Code Review
This pull request migrates the iOS quick actions example tests from XCTest to the new Swift Testing framework. The changes are generally correct and follow the new testing patterns. I've identified a few areas for improvement in the test file: some assertion messages that were present in the original tests have been lost, and one test can be made more robust to match its descriptive name. My detailed comments provide suggestions to address these points.
packages/quick_actions/quick_actions_ios/example/ios/RunnerTests/QuickActionsPluginTests.swift
Show resolved
Hide resolved
packages/quick_actions/quick_actions_ios/example/ios/RunnerTests/QuickActionsPluginTests.swift
Show resolved
Hide resolved
| waitForExpectations(timeout: 1) | ||
|
|
||
| XCTAssertEqual(invokeMethodCount, 1, "shortcut should only be handled once per launch.") | ||
| #expect(invokeMethodCount == 1) |
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.
This test's name implies that applicationDidBecomeActive is called twice, but it's only called once. To make the test align with its name and more robustly check that the shortcut is handled only once, consider calling applicationDidBecomeActive a second time. Additionally, the descriptive message from the original assertion was lost and should be restored.
// Call a second time to ensure the shortcut is not handled again.
plugin.applicationDidBecomeActive(UIApplication.shared)
#expect(invokeMethodCount == 1, "shortcut should only be handled once per launch.")
Part of flutter/flutter#180787
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8692855180982743569/+/u/Run_package_tests/native_test/stdout
Adding CHANGELOG override per #10761 (comment)
Pre-Review Checklist
[shared_preferences]pubspec.yamlwith an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under1.CHANGELOG.mdto add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under1.///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.Footnotes
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2 ↩3