Refactor iOS integration_test API to support Swift, dynamically add native tests#88013
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat. If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
fa301a9 to
090b9b0
Compare
There was a problem hiding this comment.
These build settings were automatically changed when I added a Swift file.
There was a problem hiding this comment.
Include the RunnerTests target during analysis.
There was a problem hiding this comment.
Updated and moved from IntegrationTestIosTest.h
There was a problem hiding this comment.
FLTIntegrationTestCase only works from a XCTest target (not from the app itself).
090b9b0 to
0d2b4c9
Compare
|
@stuartmorgan This refactor was larger than I was expecting... #84611 (comment) |
|
\cc @cbracken this shouldn't be too bad to also implement for macOS. The only rough edge I can think of is |
There was a problem hiding this comment.
This is slick! Out of curiosity, do we know if it's guaranteed to work? It seems a bit modifying-an-iterator-while-iterating, which makes me wonder if it has defined behavior.
There was a problem hiding this comment.
That's actually the purpose of + (NSArray<NSInvocation *> *)testInvocations--a hook for dynamically changing the test methods to use for a test case. https://stackoverflow.com/a/55204082 was a helpful reference.
There was a problem hiding this comment.
Any chance we could fix the casing of "IOS" while we're here, or is that breaking to a public API?
There was a problem hiding this comment.
That's a good idea, and there's nothing iOS-y about it other than the UIImage. I'll deprecate the entire IntegrationTestIosTest instead of just testIntegrationTest: and replace it with a FLTIntegrationTestRunner class. It would be the same result if anyone was using this API (which the docs don't say to do, but it was technically possible).
0d2b4c9 to
2488f62
Compare
| // Test deprecated macro. Do not use. | ||
| INTEGRATION_TEST_IOS_RUNNER(RunnerObjCMacroTests) | ||
|
|
||
| @interface DeprecatedIntegrationTestIosTests : XCTestCase |
There was a problem hiding this comment.
Just added this, validates the deprecated IntegrationTestIosTest still works:
Test Suite 'DeprecatedIntegrationTestIosTests' started at 2021-08-16 15:40:22.353
Test Case '-[DeprecatedIntegrationTestIosTests testIntegrationTest]' started.
2021-08-16 15:40:22.355741-0700 Runner[87799:71056731] ==================== Test Results =====================
2021-08-16 15:40:22.355888-0700 Runner[87799:71056731] verify text passed.
2021-08-16 15:40:22.355992-0700 Runner[87799:71056731] verify screenshot passed.
2021-08-16 15:40:22.356089-0700 Runner[87799:71056731] ================== Test Results End ====================
Test Case '-[DeprecatedIntegrationTestIosTests testIntegrationTest]' passed (0.004 seconds).
…ly add native tests (flutter#88013)" (flutter#88377) This reverts commit 9e3de9a.
Change the iOS native integration_tests to run the dart tests, and dynamically add the test results so that each dart test appears as a native iOS test.
FLTIntegrationTestCaseto become theXCTestCasebase class, removing the need for the Swift-incompatibleINTEGRATION_TEST_IOS_RUNNERmacro. This class swizzles a new class instance method per completed dart test.captureScreenshotrequests over the channel. Unfortunately there's no mapping to know which test it came from (yet) so they are all grouped together.FLTIntegrationTestScreenshotDelegatewith the propertyIntegrationTestPlugin.capturedScreenshotsByName. I was seeing issues where only the firstFLTIntegrationTestCasewas able to see the screenshots because newFLTIntegrationTestRunnerdelegates were being created every time. Instead, store it on the static+[IntegrationTestPlugin instance]so it's accessible from differentFLTIntegrationTestRunners.RunnerSwiftTests.swifttest file to prove it works in a Swift test.Success (note there are three instances of the tests because I created

FLTIntegrationTestCaseto test different scenarios):Failure:

Next I need to actually run the integration test during CI: #87770
Fixes #71873