Dynamic view lookup API

[nalexn]

One of the problems I'm still thinking of is the API for searching the elements. I'll give a short overview of what's technically available, and would love to hear your opinion / suggestions.

The number of SwiftUI view types is quite large and will only keep growing over time, so one of the requirements to the search API will be re-using existing inspection methods, such as .hStack(), .anyView() or .text(). The introduction of custom APIs, such as .texts(), for each view type does not make sense to me.

A way to make sure a certain view exists in the hierarchy could look like this:

XCTAssertNoThrow(try sut.inspect().find(where: { try $0.text().string() == "abc" }))

If the search does not throw, the result will be an "anonymous" view (ViewType.ClassifiedView), because the specific type of the found view cannot be inferred from the where closure.

This means, if we wanted to operate with the found view, we'd need to extract it explicitly after searching:

try sut.inspect().find(where: { try $0.text().string() == "abc" }).text() // obtained a typed view

It is possible to combine the search with unwrapping a specific type of view, but this can be available for simple intent such as "find me the first HStack in the hierarchy you stumble upon":

try sut.inspect().find().hStack() // typed view

I want the search to be seamlessly integrated with the traditional inspection chain, so you could activate it at any step:

try sut.inspect().anyView().hStack().find(where: { ... }).button().tap()

Another feature that I want to make available is moving outward in the hierarchy: from the found view back to parent views. This way you can quickly locate the right branch in the view tree by searching for a specific text, for example, and then step back to inspect the parent view, which is the true target of the test:

let view = try sut.inspect().find(where: { try $0.text().string() == "abc" }).parent().view(CustomView.self)
// inspect the CustomView

Although moving backward is a simple iteration along a linked list of "ancestor" views, I haven't decided if we need an API like .findBack(where: { try? $0.hStack() != nil } to find a predecessor view of type HStack.

To sum up, below is the list of technically available features I need to design a convenient and concise API for:

1. Search inwards by a predicate (result - anonymous view)
2. Search inwards by a specific view type (result - typed view)
3. Shifting inspection focus to a parent view (result - anonymous view)
4. Search outwards by a predicate (result - anonymous view)
5. Search outwards by a specific view type (result - typed view)

Since we need to move inward and outward, I'm considering the following namings:

1. find / findBack
2. traverse / reverse
3. search / searchBack
4. Your variant?

Lastly, I want to explore the option of making the .find() returning a BidirectionalCollection. This way, it'd allow for more flexibility in tests, for example:

try sut.inspect().tree().first(where: { try? $0.text().string() == "abc" })
// can also do .filter(where: ...).count
// .last(where: ...)
// etc.

but this would make the most common use case less convenient:

try sut.inspect().tree().first(where: { try? $0.text().string() == "abc" })!.text()
// have to unwrap Optional either in an unsafe manner (!) or use XCTUnwrap
// safe unwrap (?) will give an Optional chain, which won't execute the rest of the inspection
// in case of nil and can lead to false positives, when the test passes while it shouldn't.

[joemasilotti]

What if the first() or find() methods had a parameter that was the concrete type?

let text = try sut.inspect().tree().first(Text.self, where: { try? $0.string() == "abc" })

This offers two benefits, the developer doesn't have to caste after getting the view back. And the algorithm can skip leaf-node views that aren't the specified type.

[nalexn]

@joemasilotti

Yep, I think API like that will be available. I figured out this can be added as an extension to the main API:

let text = try sut.inspect().tree.text(containing: "abc") // Text

// Helper extension:
extension InspectableView where View == ViewType.Traverse {
    func text(containing string: String) throws -> InspectableView<ViewType.Text> {
        return try first(where { try? $0.text().string() == string }).text() 
    }
}

Although such extensions can be added on the client's side, I can include a few in the library.
Searching for a text, view by id, things like that.

Also, I think APIs like first(where), last(where), filter(where) might be really useful in testing, but I might need to opt-out of adopting BidirectionalCollection. The result should be non-optional and throwing instead of returning nil.

Current naming:

try sut.inspect().inwardViews().first(where ...)
try sut.inspect().inwardViews().filter(where ...).count   // does all(where ) sound better?
try sut.inspect().outwardViews().last(where ...)

[nalexn]

After thinking more about it, I tend to agree with you that specifying the view type is more convenient. The extensions that I was talking about would also work in this case.

[joemasilotti]

Nice! That feels like the best DX to me, coming from UI Testing and Capybara and such.

[joemasilotti]

In my opinion, using first, filter, and last would be (test) code smells. There should only be one element on the screen matching the specific query. If there's more than one they should either be a) uniquely identified or b) the developer only cares how many there are.

But that's more best practices and maybe doesn't translate directly to a framework!

[nalexn]

What if you want to run the same inspection forEach view that matches the query? Say, for each Text which font is caption assert the color value.

[nalexn]

And again, such API can be available for flexibility, while we could add aliases and shortcuts for any query that looks too bulky"

func count(where: ...) -> Int {
    return try inwardViews().filter(where: ...).count
}

try sut.inspect().count(where: ...)

[joemasilotti]

That's totally fair. From a framework's perspective this needs to be implemented. Just calling out how I think about tests!