Skip to content

Commit 873204c

Browse files
authored
DocC and XCTUnimplemented cleanup (#17)
* DocC and XCTUnimplemented cleanup * wip
1 parent 53899d6 commit 873204c

File tree

6 files changed

+266
-241
lines changed

6 files changed

+266
-241
lines changed
Lines changed: 130 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
1+
# Getting Started
2+
3+
<!--@START_MENU_TOKEN@-->Summary<!--@END_MENU_TOKEN@-->
4+
5+
## Overview
6+
7+
A real world example of using this is in our library, the [Composable Architecture](https://github.com/pointfreeco/swift-composable-architecture). That library vends a `TestStore` type whose purpose is to make it easy to write tests for your application's logic. The `TestStore` uses `XCTFail` internally, and so that forces us to move the code to a dedicated test support module. However, due to how SPM works you cannot currently have that module in the same package as the main module, and so we would be forced to extract it to a separate _repo_. By loading `XCTFail` dynamically we can keep the code where it belongs.
8+
9+
As another example, let's say you have an analytics dependency that is used all over your application:
10+
11+
```swift
12+
struct AnalyticsClient {
13+
var track: (Event) -> Void
14+
15+
struct Event: Equatable {
16+
var name: String
17+
var properties: [String: String]
18+
}
19+
}
20+
```
21+
22+
If you are disciplined about injecting dependencies, you probably have a lot of objects that take an analytics client as an argument (or maybe some other fancy form of DI):
23+
24+
```swift
25+
class LoginViewModel: ObservableObject {
26+
...
27+
28+
init(analytics: AnalyticsClient) {
29+
...
30+
}
31+
32+
...
33+
}
34+
```
35+
36+
When testing this view model you will need to provide an analytics client. Typically this means you will construct some kind of "test" analytics client that buffers events into an array, rather than sending live events to a server, so that you can assert on what events were tracked during a test:
37+
38+
```swift
39+
func testLogin() {
40+
var events: [AnalyticsClient.Event] = []
41+
let viewModel = LoginViewModel(
42+
analytics: .test { events.append($0) }
43+
)
44+
45+
...
46+
47+
XCTAssertEqual(events, [.init(name: "Login Success")])
48+
}
49+
```
50+
51+
This works really well, and it's a great way to get test coverage on something that is notoriously difficult to test.
52+
53+
However, some tests may not use analytics at all. It would make the test suite stronger if the tests that don't use the client could prove that it's never used. This would mean when new events are tracked you could be instantly notified of which test cases need to be updated.
54+
55+
One way to do this is to create an instance of the `AnalyticsClient` type that simply performs an `XCTFail` inside the `track` endpoint:
56+
57+
```swift
58+
import XCTest
59+
60+
extension AnalyticsClient {
61+
static let unimplemented = Self(
62+
track: { _ in XCTFail("\(Self.self).track is unimplemented.") }
63+
)
64+
}
65+
```
66+
67+
With this you can write a test that proves analytics are never tracked, and even better you don't have to worry about buffering events into an array anymore:
68+
69+
```swift
70+
func testValidation() {
71+
let viewModel = LoginViewModel(
72+
analytics: .unimplemented
73+
)
74+
75+
...
76+
}
77+
```
78+
79+
However, you cannot ship this code with the target that defines `AnalyticsClient`. You either need to extract it out to a test support module (which means `AnalyticsClient` must also be extracted), or the code must be confined to a test target and thus not shareable.
80+
81+
However, with XCTest Dynamic Overlay we can have our cake and eat it too 😋. We can define both the client type and the unimplemented instance right next to each in application code without needing to extract out needless modules or targets:
82+
83+
```swift
84+
struct AnalyticsClient {
85+
var track: (Event) -> Void
86+
87+
struct Event: Equatable {
88+
var name: String
89+
var properties: [String: String]
90+
}
91+
}
92+
93+
import XCTestDynamicOverlay
94+
95+
extension AnalyticsClient {
96+
static let unimplemented = Self(
97+
track: { _ in XCTFail("\(Self.self).track is unimplemented.") }
98+
)
99+
}
100+
```
101+
102+
XCTest Dynamic Overlay also comes with a helper that simplifies this exact pattern: `XCTUnimplemented`. It creates failing closures for you:
103+
104+
```swift
105+
extension AnalyticsClient {
106+
static let unimplemented = Self(
107+
track: XCTUnimplemented("\(Self.self).track")
108+
)
109+
}
110+
```
111+
112+
And it can simplify the work of more complex dependency endpoints, which can throw or need to return a value:
113+
114+
```swift
115+
struct AppDependencies {
116+
var date: () -> Date = Date.init,
117+
var fetchUser: (User.ID) async throws -> User,
118+
var uuid: () -> UUID = UUID.init
119+
}
120+
121+
extension AppDependencies {
122+
static let unimplemented = Self(
123+
date: XCTUnimplemented("\(Self.self).date", placeholder: Date()),
124+
fetchUser: XCTUnimplemented("\(Self.self).fetchUser"),
125+
date: XCTUnimplemented("\(Self.self).uuid", placeholder: UUID())
126+
)
127+
}
128+
```
129+
130+
The above `placeholder` parameters can be left off, but will fatal error when the endpoint is called.
Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
# Overloads
2+
3+
Various overloads of `XCTUnimplemented` for a number of closure types.
4+
5+
## Overview
6+
7+
`XCTUnimplemented` is a massively-overloaded function that can satisfy a number of different closure types (throwing, async, etc.) up to an arity of 5 arguments.
8+
9+
## Topics
10+
11+
### Functions
12+
13+
- ``XCTUnimplemented(_:placeholder:file:line:)-4cefg``
14+
- ``XCTUnimplemented(_:)-1jjkb``
15+
- ``XCTUnimplemented(_:placeholder:file:line:)-50but``
16+
- ``XCTUnimplemented(_:)-1tmq0``
17+
- ``XCTUnimplemented(_:placeholder:file:line:)-2jqzu``
18+
- ``XCTUnimplemented(_:)-4iv80``
19+
- ``XCTUnimplemented(_:placeholder:file:line:)-9mvva``
20+
- ``XCTUnimplemented(_:)-2hloh``
21+
- ``XCTUnimplemented(_:placeholder:file:line:)-92nev``
22+
- ``XCTUnimplemented(_:)-6skqm``
23+
- ``XCTUnimplemented(_:placeholder:file:line:)-6wlpq``
24+
- ``XCTUnimplemented(_:)-9llzg``
25+
- ``XCTUnimplemented(_:placeholder:file:line:)-97hr8``
26+
- ``XCTUnimplemented(_:)-1osc7``
27+
- ``XCTUnimplemented(_:placeholder:file:line:)-qhqq``
28+
- ``XCTUnimplemented(_:)-26rd5``
29+
- ``XCTUnimplemented(_:placeholder:file:line:)-4akkm``
30+
- ``XCTUnimplemented(_:)-7j8g3``
31+
- ``XCTUnimplemented(_:placeholder:file:line:)-5i77i``
32+
- ``XCTUnimplemented(_:)-1qks2``
33+
- ``XCTUnimplemented(_:placeholder:file:line:)-4xhs3``
34+
- ``XCTUnimplemented(_:)-6r8mf``
Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
# ``XCTestDynamicOverlay``
2+
3+
Define XCTest assertion helpers directly in your application and library code.
4+
5+
## Overview
6+
7+
XCTest Dynamic Overlay provides APIs for invoking XCTest's `XCTFail` directly in your application and library code.
8+
9+
## Topics
10+
11+
### Essentials
12+
13+
- <doc:GettingStarted>
14+
15+
<!--NB: A DocC bug prevents the functions from resolving:-->
16+
<!--### XCTFail-->
17+
<!---->
18+
<!--- ``XCTFail(_:)-30at6``-->
19+
<!--- ``XCTFail(_:file:line:)-3ujuf``-->
20+
21+
### Unimplemented Dependencies
22+
23+
- ``XCTUnimplemented(_:placeholder:file:line:)-l4v2``
24+
- ``XCTUnimplemented(_:)-3obl5``
25+
- <doc:UnimplementedOverloads>
26+
- ``XCTUnimplementedFailure``

0 commit comments

Comments
 (0)