[webview_flutter] Convert from XCTest to Swift Testing

[stuartmorgan-g]

Converts all of the webview_flutter unit tests from XCTest to Swift testing. This was mostly done by Gemini (mostly purely mechanical conversion), with some minor cleanup after I reviewed it. As with other conversions, this is focused on converting more or less directly, without adopting new features like parameterization.

Part of flutter/flutter#180787

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.

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. ↩ ↩²

[gemini-code-assist]

Code Review

This pull request migrates the unit tests for the WKWebView implementation from the XCTest framework to the Swift Testing framework. The changes include replacing XCTest assertions with #expect, converting test classes to @Suite structs, and updating asynchronous test patterns to use modern Swift concurrency. The review feedback suggests using the Skip error to dynamically skip tests instead of returning early, and using #expect(throws: Never.self) to assert that no error is thrown instead of using withKnownIssue.

[LongCatIsLooong]

It looks like gemini is making some strange choices around async and throw tests. Most comments aren't blocking except the timeout one.

[LongCatIsLooong]

Uhm I have not used swift testing that much, but this doesn't look right. How can you throw a Never if you can't construct one in the first place? So from reading this the expectation seems to be "the closure never throws"?

[LongCatIsLooong]

Oh I see gemini code review suggested that and the expectation is indeed "the closure does not throw". Never mind then. Although the testing framework treats all uncaught exceptions as failures so the Never.self is probably not really needed.

[stuartmorgan-g]

I dug into this test more, and the structure is even weirder than it seemed at first glance because the method being called isn't throws. So once the throws: Never.self wrapper is removed you get a warning about calling try on something that doesn't throw.

I settled for just calling the method directly in the test, and putting a comment on the test saying not to add throws to it, and why. It's a bit weird, but seemed like the simplest way of expressing what the test is trying to prevent regressing.

[LongCatIsLooong]

nit: this test doesn't actually throw does it? Since we are using try? ?

[LongCatIsLooong]

Same question for the test below.

[stuartmorgan-g]

I didn't notice how much the tests in this package used try?. I think in a Swift Testing world what we generally want is to try instead since the test system is designed to support reporting exceptions, so if something throws that was supposed to succeed it's better to get the exception than to just get a nil comparison failure in an #expect.

I scrubbed try? out of everything but the constructor tests. For those the explicit nil check seemed cleaner than a comment saying why there's no check, so I removed throws from just those.

[LongCatIsLooong]

IIRC withCheckedThrowingContinuation or @Test never times out by itself unless explicitly given a timeout value. Here if continuation.resume is never called, I suspect the test will hang.

[LongCatIsLooong]

Also this test reads a bit weird since gemini went out of its way to type the continuation CheckedContinuation<Bool, Error> but never actually uses the return value.

[stuartmorgan-g]

IIRC withCheckedThrowingContinuation or @Test never times out by itself unless explicitly given a timeout value. Here if continuation.resume is never called, I suspect the test will hang.

Yeah. In theory that's a feature (see here and here), so it's how we've been doing Swift Testing conversions.

I will say I don't love the dev experience, so longer term we may want to have a Flutter-team-level discussion around this. It was already kind of annoying for manual development, but what I discovered while doing this round of conversions using Gemini instead of doing it manually is that it's quite bad for agentic development because the agent will frequently make a bunch of changes, kick of the tests to see how they turn out, and then just say "Now I'll wait for the tests to finish"... and just wait forever until a human intercedes.

[stuartmorgan-g]

(If we do later decided to move away from tests that can hang forever, I think we would sweep the entire repo and add timeLimit traits to everything at a suite level.)