-
Notifications
You must be signed in to change notification settings - Fork 19
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
Refactored SwiftUI tests to use async/await APIs #171
Conversation
…ing, but async await looks like it means we can get rid of that stupid removeQueuedExpectations thing - TT
…it seems, but the tests needed to up the iOS version - TT
… and got rid of queued expectations entirely - TT
…ompiler issues in other modules but I don't care because this whole thing is just going to be slow going - TT
…ause...reasons I dont know, view inspector made me - TT
…ut refactoring them is NOT FUN - TT
I recognize this refactor can be hard to grok. Here's your key takeaway. I am turning this horrible pyramid of doom: func testRemovedAfterProceeding_OnMiddleItemInAWorkflow() throws {
struct FR1: View, FlowRepresentable, Inspectable {
var _workflowPointer: AnyFlowRepresentable?
var body: some View { Text("FR1 type") }
}
struct FR2: View, FlowRepresentable, Inspectable {
var _workflowPointer: AnyFlowRepresentable?
var body: some View { Text("FR2 type") }
}
struct FR3: View, FlowRepresentable, Inspectable {
var _workflowPointer: AnyFlowRepresentable?
var body: some View { Text("FR3 type") }
}
struct FR4: View, FlowRepresentable, Inspectable {
var _workflowPointer: AnyFlowRepresentable?
var body: some View { Text("FR4 type") }
}
let expectViewLoaded = ViewHosting.loadView(
WorkflowLauncher(isLaunched: .constant(true)) {
thenProceed(with: FR1.self) {
thenProceed(with: FR2.self) {
thenProceed(with: FR3.self) {
thenProceed(with: FR4.self)
}
}
.persistence(.removedAfterProceeding)
}
}
).inspection.inspect { fr1 in
XCTAssertNoThrow(try fr1.find(FR1.self).actualView().proceedInWorkflow())
try fr1.actualView().inspectWrapped { fr2 in
XCTAssertNoThrow(try fr2.find(FR2.self).actualView().proceedInWorkflow())
try fr2.actualView().inspectWrapped { fr3 in
XCTAssertNoThrow(try fr3.find(FR3.self).actualView().backUpInWorkflow())
try fr1.actualView().inspect { fr1 in
XCTAssertNoThrow(try fr1.find(FR1.self).actualView().proceedInWorkflow())
try fr1.actualView().inspectWrapped { fr2 in
XCTAssertNoThrow(try fr2.find(FR2.self).actualView().proceedInWorkflow())
try fr2.actualView().inspectWrapped { fr3 in
XCTAssertNoThrow(try fr3.find(FR3.self).actualView().proceedInWorkflow())
try fr3.actualView().inspectWrapped { fr4 in
XCTAssertNoThrow(try fr4.find(FR4.self).actualView().proceedInWorkflow())
}
}
}
}
}
}
}
wait(for: [expectViewLoaded], timeout: TestConstant.timeout)
} into this much less horrible serial set of tests func testRemovedAfterProceeding_OnMiddleItemInAWorkflow() async throws {
struct FR1: View, FlowRepresentable, Inspectable {
var _workflowPointer: AnyFlowRepresentable?
var body: some View { Text("FR1 type") }
}
struct FR2: View, FlowRepresentable, Inspectable {
var _workflowPointer: AnyFlowRepresentable?
var body: some View { Text("FR2 type") }
}
struct FR3: View, FlowRepresentable, Inspectable {
var _workflowPointer: AnyFlowRepresentable?
var body: some View { Text("FR3 type") }
}
struct FR4: View, FlowRepresentable, Inspectable {
var _workflowPointer: AnyFlowRepresentable?
var body: some View { Text("FR4 type") }
}
let launcher = try await MainActor.run {
WorkflowLauncher(isLaunched: .constant(true)) {
thenProceed(with: FR1.self) {
thenProceed(with: FR2.self) {
thenProceed(with: FR3.self) {
thenProceed(with: FR4.self)
}
}
.persistence(.removedAfterProceeding)
}
}
}.hostAndInspect(with: \.inspection)
try await launcher.find(FR1.self).proceedInWorkflow()
try await launcher.find(FR2.self).proceedInWorkflow()
try await launcher.find(FR3.self).backUpInWorkflow()
try await launcher.find(FR1.self).proceedInWorkflow()
try await launcher.find(FR2.self).proceedInWorkflow()
try await launcher.find(FR3.self).proceedInWorkflow()
try await launcher.find(FR4.self).proceedInWorkflow()
} |
…t refactor is still worth it - TT
…ning out really nice - TT
…ickier than I expected - TT
…t them for now - TT
…ways to go and some issues with navs and modals - TT
…12 is not available - TT
…ng one that never could have worked correctly - TT
… still some nav links to go but the races are solved - TT
…uting UI stuff on a background thread - TT
…ng on the wrong thread - TT
…aced, all FIXMEs have been fixed - TT
WARNING DANGER WILL ROBINSON: So this works, and the refactor is definitely nicer to read and work with. However, our pipeline is failing on timeouts. I've run this on really poor machines and on really performant machines. I do not believe it's timing out because there's a case. I believe it's timing out because the pipeline is not on Monterrey. So despite the new test niceties, we cannot merge this without our pipeline failing :( |
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.
Start of the review.
Tests/SwiftCurrent_SwiftUITests/ViewInspector/ViewHostingExtensions.swift
Show resolved
Hide resolved
Co-authored-by: Matt Freiburg <Matt.Freiburg@wwt.com>
Codecov Report
@@ Coverage Diff @@
## main #171 +/- ##
=======================================
Coverage 91.28% 91.28%
=======================================
Files 92 92
Lines 2375 2375
=======================================
Hits 2168 2168
Misses 207 207 Continue to review full report at Codecov.
|
Linked Issue:
Checklist:
If Applicable: