A collection of tools for debugging, diffing, and testing your application's data structures.
Swift comes with a wonderful tool for dumping the contents of any value to a string, and it's called dump. It prints all the fields and sub-fields of a value into a tree-like description:
struct User {
var favoriteNumbers: [Int]
var id: Int
var name: String
}
let user = User(
favoriteNumbers: [42, 1729],
id: 2,
name: "Blob"
)
dump(user)▿ User
▿ favoriteNumbers: 2 elements
- 42
- 1729
- id: 2
- name: "Blob"
This is really useful, and can be great for building debug tools that visualize the data held in runtime values of our applications, but sometimes its output is not ideal.
For example, dumping dictionaries leads to a verbose output that can be hard to read (also note that the keys are unordered):
dump([1: "one", 2: "two", 3: "three"])▿ 3 key/value pairs
▿ (2 elements)
- key: 2
- value: "two"
▿ (2 elements)
- key: 3
- value: "three"
▿ (2 elements)
- key: 1
- value: "one"
Similarly enums have a very verbose output:
dump(Result<Int, Error>.success(42))▿ Swift.Result<Swift.Int, Swift.Error>.success
- success: 42
It gets even harder to read when dealing with deeply nested structures:
dump([1: Result<User, Error>.success(user)])▿ 1 key/value pair
▿ (2 elements)
- key: 1
▿ value: Swift.Result<User, Swift.Error>.success
▿ success: User
▿ favoriteNumbers: 2 elements
- 42
- 1729
- id: 2
- name: "Blob"
There are also times that dump simply does not print useful information, such as enums imported from Objective-C:
import UserNotifications
dump(UNNotificationSetting.disabled)- __C.UNNotificationSetting
So, while the dump function can be handy, it is often too crude of a tool to use. This is the motivation for the customDump function.
The customDump function emulates the behavior of dump, but provides a more refined output of nested structures, optimizing for readability. For example, structs are dumped in a format that more closely mimics the struct syntax in Swift, and arrays are dumped with the indices of each element:
import CustomDump
customDump(user)User(
favoriteNumbers: [
[0]: 42,
[1]: 1729
],
id: 2,
name: "Blob"
)
Dictionaries are dumped in a more compact format that mimics Swift's syntax, and automatically orders the keys:
customDump([1: "one", 2: "two", 3: "three"])[
1: "one",
2: "two",
3: "three"
]
Similarly, enums also dump in a more compact, readable format:
customDump(Result<Int, Error>.success(42))Result.success(42)
And deeply nested structures have a simplified tree-structure:
customDump([1: Result<User, Error>.success(user)])[
1: Result.success(
User(
favoriteNumbers: [
[0]: 42,
[1]: 1729
],
id: 2,
name: "Blob"
)
)
]
Using the output of the customDump function we can build a very lightweight way to textually diff any two values in Swift:
var other = user
other.favoriteNumbers[1] = 91
print(diff(user, other)!) User(
favoriteNumbers: [
[0]: 42,
- [1]: 1729
+ [1]: 91
],
id: 2,
name: "Blob"
)Further, extra work is done to minimize the size of the diff when parts of the structure haven't changed, such as a single element changing in a large collection:
let users = (1...5).map {
User(
favoriteNumbers: [$0],
id: $0,
name: "Blob \($0)"
)
}
var other = users
other.append(
.init(
favoriteNumbers: [42, 1729],
id: 100,
name: "Blob Sr."
)
)
print(diff(users, other)!) [
… (4 unchanged),
+ [4]: User(
+ favoriteNumbers: [
+ [0]: 42,
+ [1]: 1729
+ ],
+ id: 100,
+ name: "Blob Sr."
+ )
]For a real world use case we modified Apple's Landmarks tutorial application to print the before and after state when favoriting a landmark:
[
[0]: Landmark(
id: 1001,
name: "Turtle Rock",
park: "Joshua Tree National Park",
state: "California",
description: "This very large formation lies south of the large Real Hidden Valley parking lot and immediately adjacent to (south of) the picnic areas.",
- isFavorite: true,
+ isFavorite: false,
isFeatured: true,
category: Category.rivers,
imageName: "turtlerock",
coordinates: Coordinates(…)
),
… (11 unchanged)
]XCTest's XCTAssertEqual and Swift Testing's #expect(_ == _) both allow you to assert that two values are equal, and if they are not the test suite will fail with a message:
var other = user
other.name += "!"
XCTAssertEqual(user, other)
#expect(user == other)XCTAssertEqual failed: ("User(favoriteNumbers: [42, 1729], id: 2, name: "Blob")") is not equal to ("User(favoriteNumbers: [42, 1729], id: 2, name: "Blob!")")
Expectation failed: (user → User(favoriteNumbers: [42, 1729], id: 2, name: "Blob")) == (other → User(favoriteNumbers: [42, 1729], id: 2, name: "Blob!"))
Unfortunately these failure messages are quite difficult to visually parse and understand. It takes a few moments of hunting through the message to see that the only difference is the exclamation mark at the end of the name. The problem gets worse if the type is more complex, consisting of nested structures and large collections.
This library also ships with an expectNoDifference function to mitigate these problems. It works like XCTAssertEqual and #expect(_ == _) except the failure message uses a nicely formatted diff to show exactly what is different between the two values:
expectNoDifference(user, other)expectNoDifference failed: …
User(
favoriteNumbers: […],
id: 2,
- name: "Blob"
+ name: "Blob!"
)
(First: −, Second: +)This function provides the inverse of expectNoDifference: it asserts that a value has a set of changes by evaluating a given expression before and after a given operation and then comparing the results.
For example, given a very simple counter structure, we can write a test against its incrementing functionality:
struct Counter {
var count = 0
var isOdd = false
mutating func increment() {
self.count += 1
self.isOdd.toggle()
}
}
var counter = Counter()
expectDifference(counter) {
counter.increment()
} changes: {
$0.count = 1
$0.isOdd = true
}If the changes does not exhaustively describe all changed fields, the assertion will fail.
By omitting the operation you can write a "non-exhaustive" assertion against a value by describing just the fields you want to assert against in the changes closure:
counter.increment()
expectDifference(counter) {
$0.count = 1
// Don't need to further describe how `isOdd` has changed
}Custom Dump provides a few important ways to customize how a data type is dumped: CustomDumpStringConvertible, CustomDumpReflectable, and CustomDumpRepresentable.
The CustomDumpStringConvertible protocol provides a simple way of converting a type to a raw string for the purpose of dumping. It is most appropriate for types that have a simple, un-nested internal representation, and typically its output fits on a single line, for example dates, UUIDs, URLs, etc:
extension URL: CustomDumpStringConvertible {
public var customDumpDescription: String {
"URL(\(self.absoluteString))"
}
}
customDump(URL(string: "https://www.pointfree.co/")!)URL(https://www.pointfree.co/)
Custom Dump also uses this protocol internally to provide more useful output for enums imported from Objective-C:
import UserNotifications
print("dump:")
dump(UNNotificationSetting.disabled)
print("customDump:")
customDump(UNNotificationSetting.disabled)dump:
- __C.UNNotificationSetting
customDump:
UNNotificationSettings.disabled
Encounter an Objective-C enum that doesn't print nicely? See the contributing section of this README to help submit a fix.
The CustomDumpReflectable protocol provides a more comprehensive way of dumping a type into a more structured output. It allows you to construct a custom mirror that describes the structure that should be dumped. You can omit, add, and replace fields, or even change the "display style" of how the structure is dumped.
For example, let's say you have a struct representing state that holds a secure token in memory that should never be written to your logs. You can omit the token from customDump by providing a mirror that omits this field:
struct LoginState: CustomDumpReflectable {
var username: String
var token: String
var customDumpMirror: Mirror {
.init(
self,
children: [
"username": self.username,
// omit token from logs
],
displayStyle: .struct
)
}
}
customDump(
LoginState(
username: "blob",
token: "secret"
)
)LoginState(username: "blob")
And just like that, no token data will be written to the dump.
The CustomDumpRepresentable protocol allows you to return any value for the purpose of dumping. This can be useful to flatten the dump representation of wrapper types. For example, a type-safe identifier may want to dump its raw value directly:
struct ID: RawRepresentable {
var rawValue: String
}
extension ID: CustomDumpRepresentable {
var customDumpValue: Any {
self.rawValue
}
}
customDump(ID(rawValue: "deadbeef")"deadbeef"
There are many types in Apple's ecosystem that do not dump to a nicely formatted string. In particular, all enums that are imported from Objective-C dump to strings that are not very helpful:
import UserNotifications
dump(UNNotificationSetting.disabled)- __C.UNNotificationSetting
For this reason we have conformed a bunch of Apple's types to the CustomDumpStringConvertible protocol so that they print out more reasonable descriptions. If you come across types that do not print useful information then we would happily accept a PR to conform those types to CustomDumpStringConvertible.
You can add Custom Dump to an Xcode project by adding it as a package dependency.
If you want to use Custom Dump in a SwiftPM project, it's as simple as adding it to a dependencies clause in your Package.swift:
dependencies: [
.package(url: "https://github.com/pointfreeco/swift-custom-dump", from: "1.0.0")
]The latest documentation for the Custom Dump APIs is available here.
This library is released under the MIT license. See LICENSE for details.