[google_sign_in] Increase iOS coverage tests

[victogomez-cs]

Adds native unit tests for previously untested paths in FLTGoogleSignInPlugin.m before the Objective-C → Swift migration. Production code is unchanged.

This is a tests-only change, so it does not bump the package version or CHANGELOG.

Native unit tests go from 21 tests / 6 suites to 31 tests / 11 suites.

New test cases

urlHandling (iOS / Mac Catalyst only) — these APIs do not exist on macOS (handleOpenURLs: is the macOS path):

• applicationOpenURL — application:openURL:options: forwards the URL to GID and returns true
• applicationOpenURLReturnsHandleResult — same path returns false when GID does
• sceneOpenURLContexts — scene:openURLContexts: forwards the URL from a UIOpenURLContext stand-in

errorMapping:

• mapsRemainingGIDSignInErrorCodes (parameterized):
  • GIDSignInError.keychain → FSIGoogleSignInErrorCode.keychainError
  • GIDSignInError.EMM → FSIGoogleSignInErrorCode.eemError
  • GIDSignInError.unknown → FSIGoogleSignInErrorCode.unknown
  • unrecognized SDK code (12345) → FSIGoogleSignInErrorCode.unknown
• sanitizesComplexUserInfoInFlutterError — FSISanitizedUserInfo keeps strings/numbers/URLs/arrays/dicts/nested errors and stringifies unsupported types (e.g. Date)

disconnect:

• disconnectReturnsFlutterErrorOnFailure — a GID disconnect failure is returned as a Flutter error with domain/code and userInfo

userData:

• signInWithoutProfileImageOmitsPhotoUrl — a user with no profile photo gets photoUrl == nil and still maps displayName

topViewController (iOS / Mac Catalyst only) — macOS presents with NSWindow, not a UIViewController hierarchy:

• usesNavigationControllerVisibleController — presents from the nav stack’s top VC
• usesTabBarControllerSelectedController — presents from the selected tab VC
• usesPresentedViewController — presents from a presented VC

Also records URLs passed to TestSignIn.handle(_:) so the URL-handling cases can assert the fake was called.

First part of Swift migration to backfill code coverage for flutter/flutter#119103

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

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-assist bot 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

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request adds a comprehensive suite of Swift unit tests for the iOS Google Sign-In plugin, covering URL handling, error mapping, disconnect scenarios, user data parsing, and top view controller resolution. The review feedback suggests passing nil instead of a scene instance in the sceneOpenURLContexts test to prevent potential test failures in headless CI environments where connected scenes may be empty.

[gemini-code-assist]

In headless unit test environments (such as CI runners), UIApplication.shared.connectedScenes can be empty, which causes try #require(UIApplication.shared.connectedScenes.first) to throw and fail the test. Since the scene parameter is completely unused in the plugin's implementation of scene:openURLContexts:, we can pass nil instead and make the test more robust and independent of the application's scene state.

      @Test func sceneOpenURLContexts() {
        let (plugin, fakeSignIn) = createTestPlugin()
        let url = URL(string: "com.googleusercontent.apps.test:/oauthredirect")!
        let fakeContext = FakeOpenURLContext(url: url)

        plugin.perform(
          NSSelectorFromString("scene:openURLContexts:"),
          with: nil,
          with: NSSet(object: fakeContext))

        #expect(fakeSignIn.handledURLs == [url])
      }

[hellohuanlin]

please address gemini comments. It will make review easier.

[hellohuanlin]

Overall looks good. Just some nits.

[hellohuanlin]

This loses compilation safety. let's avoid using objc hacks

[victogomez-cs]

Done! Dropped scene:openURLContexts: because UIOpenURLContext has no public initializer, so the only way to call it was performSelector. Left a TODO to add a typed test after the Obj-C → Swift migration (flutter/flutter#119103).

[hellohuanlin]

please address gemini comments. It will make review easier.

[hellohuanlin]

This issue doesn't describe the problem that you are describing above though

[victogomez-cs]

You’re right, #119103 is the Swift migration tracker, not this test gap. I linked it because that is the issue we are using for this migration effort, and the typed scene:openURLContexts: test is meant to come back as part of that work. Should I drop the #119103 link from the TODO?

[hellohuanlin]

How is the previous objc hack related to UIOpenURLContext's public initializer? Can you add more info?

[victogomez-cs]

A typed call needs NSSet<UIOpenURLContext *>. UIKit marks UIOpenURLContext init/new unavailable, so tests cannot build a real context. The old test used performSelector with an NSObject stand-in, which isn’t type-checked. I expanded the TODO to spell that out, still pointing at #119103 as the migration tracker

[hellohuanlin]

This is a limitation on UIKit testing in Swift. One common workaround is to move all your logic into a method that takes a custom type, and then the original method's implementation would be just 1-liner wrapper of this new method. Then you can just test this new method. The drawback is that the 1-liner wrapper would untested, but this is acceptable since it's trivial.

[victogomez-cs]

Thanks, that makes sense. I’ll keep this PR tests-only (no production Obj-C changes) and add that seam in the Swift migration: a typed method that takes [URL], with scene:openURLContexts: as a one-line wrapper, then unit-test the new method. I’ll update the TODO to mention that pattern, unless you need the seam in this PR

[hellohuanlin]

@victogomez-cs it’s better to add it in this PR rather than deferring it. TODOs can easily get lost, and this ensures we keep test coverage solid right away.

[victogomez-cs]

Done. Extracted handleURLs: (takes [URL]) and left scene:openURLContexts: as a thin wrapper that maps UIOpenURLContext.URL. Tests call handleURLs: directly