Who said we cannot unit test SwiftUI views?

The story behind creating a unit-testing framework

Viktor Chernomyrdin, a Russian politician from the ‘90s, once said:

“Such has never happened before, and here it is again.”

This reminds me of the situation we find ourselves in with SwiftUI: We have a brand-new, exciting technology — but with stability issues, an incomplete API, and scarce documentation. Such has never happened before, and here it is again.

Anyway, things are not as bad as they could be, and teams have already started adopting SwiftUI in production projects. Still, one of the main arguments against using it in production is a complete inability to unit test the UI.

A function of state should be really straightforward to test — with one if . We need to have access to the function’s output.

Views in SwiftUI are nested inside one another, forming a statically typed hierarchy of structs without an API to inspect the view’s content.

One day Apple may release its unit testing tool for SwiftUI, but who knows whether/when this will happen.

So I decided to build one.

The Tool

Since there’s no access to the inner shadow attribute graph of SwiftUI, I tried to use Swift’s reflection API. Xcode uses it for printing out the contents of variables when we stop on a breakpoint in the debugger. And I was surprised by how much information was available inside the SwiftUI views.

It turns out SwiftUI views have a very ramified inner structure, so the first thing I had to implement was a recursive traversing of inner attributes:

If you call this function for a simple view hierarchy, like this one:

… you’d get a pretty long output. However, this could be restructured in a more readable and concise way:

"view" of type AnyView
  ↳ "storage" of type AnyViewStorage<Text>
      ↳ "view" of type Text
          ↳ "modifiers" of type Array<Modifier>
              ↳ value = []
          ↳ "storage" of type Storage
              ↳ "verbatim" of type String
                  ↳ value = "Hello, world!"

I had a gut feeling that it just can’t be that simple — there had to be a wall I won’t be able to get through with using just reflection, but I was curious how far I could dig.

And as it turned out, there were many pitfalls waiting for me on the way:

1. All types in reflection are erased to Any
2. Computed properties, such as var body: some View, are not available in reflection
3. There are generic private structs and function types, which are tricky to cast the value to
4. It’s hard to initialize a struct for which all init methods are private
5. SwiftUI dependency needs an injection through Environment
6. There are significant variations to the hierarchy after a tiny tweak of the input — for example, Text("Hi") vs. Text(hiValue)
7. Overall there’s a lot of obscurities and a lack of information about the private structures

In this article, I’ll talk about interesting use cases I encountered and the ways I addressed the challenges, but before that, let me show you what I’ve got after a few days of trial and error:

With this library, you can extract your custom views from the hierarchy and evaluate its state in unit tests:

You can read the actual values from the standard SwiftUI views, such as theString value of Text.

And it’s also possible to programmatically trigger side effects on behalf of the user:

By now, the framework supports the majority of views available in SwiftUI for iOS and macOS, as well as views ported from UIKit with UIViewRepresentable:

AnyView, Button, DatePicker, Divider, EquatableView, ForEach, Form, GeometryReader, Group, GroupBox, HSplitView, HStack, Image, List, ModifiedContent, NavigationLink, NavigationView, Picker, ScrollView, Section, SecureField, Slider, Stepper, TabView, Text, TextField, Toggle, VSplitView, VStack, ZStack

I did eventually hit a few unbreakable walls, but overall, I’m satisfied with the result.

OK, it’s time for some hacky stories.

Creating a Struct Without Calling init()

There is one interesting SwiftUI view that provides information about the view’s container size: GeometryReader.

The reflection showed this view doesn’t store the contained view directly. Instead, it holds a closure for building the enclosed views. The closure takes one parameter — the GeometryProxy value.

This means the only way to obtain the Text view in the example above is to call that closure with a GeometryProxy.

OK, fortunately, GeometryProxy is a public struct, but it doesn’t have any public initializers.

How can we construct a value without a factory?

Value types, as opposed to objects, don't require storing pointers to the parent class for self-identification, meaning they remain functional without isa pointers inside ... I had one crazy idea in my mind, and I decided to try it.

At first, I wanted to find out the number of bytes that GeometryProxy takes. Swift provides MemoryLayout for this purpose:

MemoryLayout<GeometryProxy>.size
>> 48

There are two options of where you can allocate the memory: on the stack and on the heap.

The latter is more flexible, as you can just specify the number of bytes you need:

let pointer = UnsafeMutableRawBufferPointer
                  .allocate(byteCount: 48, alignment: 8)

But dynamic memory requires manual deallocation with deallocate() and is slower than allocation on the stack, so I decided to go with the first option, which is more exotic.

I needed to declare a value type that’d take the same amount of bytes: 48. I called MemoryLayout for a Double and, expectedly, got the following:

MemoryLayout<Double>.size
>> 8

So if I declared a struct, for example, that kept six doubles. Its total memory size should be 48:

struct Allocator {
    let data: (Double, Double, Double, 
               Double, Double, Double) = (0, 0, 0, 0, 0, 0)
}
MemoryLayout<Allocator>.size
>> 48

Great! The last step was to cast the types:

let proxy = unsafeBitCast(Allocator(), to: GeometryProxy.self)

It's alive. Alive!

Of course, there were no guarantees the fake GeometryProxy would work correctly, as the inner variables may not expect to be zeros, but, fortunately, this worked well:

proxy.size
>> CGSize(0, 0)

I had an idea to find the position of bytes responsible for storing the CGSize and to initialize them with the custom value. But reflection showed that size, just like all the other public vars on GeometryProxy are computed, so there was no way to achieve this.

So after I called the factory closure on the GeometryReader with this Frankenstein struct, I got the contained views with no issues. Of course, the layout of the views is screwed, but at least the values, like the string on Text, could be safely extracted.

Casting to an Unknown Generic Type

Another notable case was with ForEach. To explore the internals, I made a simple setup with an array of strings transformed to Text views:

let array = ["0", "1", "2"]
let view = ForEach(array, id: \.self) { Text($0) }

My BFG10K function attributesTree(value:) showed the following:

"view" of type ForEach<Array<String>, String, Text>
  ↳ "data" of type Array<String>
      ↳ value = ["0", "1", "2"]
  ↳ "content" of type (String) -> Text
  ↳ "idGenerator" of type WritableKeyPath<String, String>
      ↳ value = WritableKeyPath<String, String>
  ↳ "contentID" of type Int
      ↳ value = 0

So I could extract the Text views using the content-builder closure content: (String) -> Text by providing it with an element of the data: [String] array.

All I needed to do was cast data and content to correct types from reflection's default type Any:

Hardcoding types String and Text, of course, wouldn't work for an arbitrary ForEach, so I needed to get the types from elsewhere.

A naive attempt to obtain the type dynamically with type(of: value) didn’t make the compiler happy — it needs to know the types in compile time. Basically, this is not a valid code: let casted = value as? type(of: value).

OK, the type information should be known at compile time. Where can we get it from?

The first workable solution I came up with was to provide the types from the caller side:

I didn’t like this approach because it was bulky and inconvenient to use, so I appealed to the following hack.

I’ve declared a type-erased middleware protocol and extended the ForEach to conform to that protocol. The trick is that in the extension of theForEach we have the inner type information required for the content extraction:

So the original extraction function now just needed to cast the view: Any to the middleware protocol and call extractContent(). Since ForEach now conforms to that protocol, the cast succeeds, and the extraction works as expected:

SwiftUI’s Native Environment Injection

SwiftUI has a very handy dependency injection mechanism through @ObservedObject, @EnvironmentObject, and @Environment attributes.

While there was no practical problem with supporting @ObservedObject in the inspection framework, I had to spend quite some time trying to figure out how to inject @EnvironmentObject.

When a view receives a traditional DI injection through .environmentObject(...), it gets wrapped into a view of the type ModifiedContent. This type of view is widely used throughout SwiftUI for applying various tweaks to the view, such as .padding(), .blur(radius:), etc.

ModifiedContent is quite transparent — one of its attributes, called content, provides the enclosed view, which could be easily extracted.

The problem was with the other attribute, modifier, which usually refers to the value of a semiprivate type, such as _PaddingLayout. I called them semiprivate because Xcode recognizes these types if you paste them in the source code, but their symbols are excluded from the public headers. If you control-click and select "Jump to Definition," Xcode won't be able to locate them.

For some types, Xcode Autocomplete shows a few instance vars — for example, _PaddingLayout has var edges: Edge.Set and var insets: EdgeInsets?.

So going back to the problem of injecting @EnvironmentObject: The view gets wrapped in a ModifiedContent in which the modifier has the type _EnvironmentKeyWritingModifier<InjectedObject?>.

That modifier has no public methods, and here’s what reflection shows for it when we inject an object of type InjectedObject:

"modifier" of type _EnvironmentKeyWritingModifier<InjectedObject?>
   ↳ "keyPath" of type WritableKeyPath
       ↳ value = WritableKeyPath<EnvironmentValues, InjectedObject?>
   ↳ "value" of type InjectedObject?
       ↳ value = InjectedObject(...)

It does keep the reference to the InjectedObject and also has a WritableKeyPath for EnvironmentValues.

Those EnvironmentValues are very mysterious. So far I know both @EnvironmentObject and @Environment are using it for storing the values used by the SwiftUI views, but my experiments showed that the EnvironmentValues are provided to the view hierarchy only at the render time – and withdrawn after.

Try running the following code:

You’ll see the asynchronous reading of @EnvironmentObject outside of the rendering cycle is prohibited — you'll get the same crash as if you never provided InjectedObject in the .environmentObject(...) call.

Design Decisions Behind the Inspection Framework

I wanted to make the library safe and convenient to use. All I had was just an idea how the syntax on the caller side should look like: It should be chained to calls like view.anyView.hStack.button.

It was clear each intermediate element should return a statically typed value that’d restrict the available options: There’s no sense of calling .tap() for AnyView or .hStack on a Text.

One of the options was to create an object-oriented hierarchy of classes, but after using functional and protocol-oriented programming for a few years, I developed a strong allergy to OOP.

So I decided to use a unified struct, InspectableView, and encapsulate the polymorphic behavior in its generic parameter View:

struct InspectableView<View> {
    let view: Any
}

At first, I thought I’d be using SwiftUI views as the View parameter, but I quickly realized most of the SwiftUI views have generic parameters as well. Constructions like InspectableView<HStack<VStach<Text>>> would be too cumbersome and fragile to operate.

Instead, I’ve created an empty struct ViewType { } that served as the base namespace for future view type — ViewType.Button being a representative for the Button view, for example.

I thought the user of the library could falsely assume they can substitute SwiftUI views in that parameter. In order to help them quickly identify this is the wrong path, I’ve put a restriction on the generic type to conform to a simple protocol KnownViewType, which SwiftUI views don't conform to by default:

Now it was all ready to start building the polymorphic behavior with generics.

The views in SwiftUI can either contain a single view (AnyView), a collection of views (HStack), or no other views (Text).

In order to encapsulate this behavior, I defined two protocols: SingleViewContentand MultipleViewContent.

Now any ViewType was able to adopt the content-extraction strategy based on its nature:

For views like Text that don't have a contained view, its companion ViewType.Text simply opts out of conforming to either of these protocols.

Now every ViewType could declare its strategy of extracting the content.

The last piece of the puzzle was to add methods, such as .hStack for extraction from the parent.

This one was easy — I just extended InspectableView where View: SingleViewContent with a method named after the type of view intended for extraction, allowing such views to continue the chain with .hStack, for example:

A similar extension was defined for MultipleViewContent as well.

Finally, for types like ViewType.Button, I could add exclusive support of the methods like .tap().

With this approach InspectableView obtained a controlled set of methods available for a particular ViewType, eliminating the possible logical errors when working with the view-extraction library.

Conclusion

That’s the story behind creating the ViewInspector framework. If you have a SwiftUI project you want to cover with unit yests — consider trying it out.

If you want to better understand the inner SwiftUI mechanisms used under the hood, take that function attributesTree(value:), and crack those black-boxed views.