Unit exams must be as freed from exterior dependencies as attainable. Which means that you wish to have full management over the whole lot that occurs in your exams.
For instance, for those who’re working with a database, you need the database to be empty or in some predefined state earlier than your check begins. You use on the database throughout your check and after your check the database will be thrown away.
By making your exams not rely on exterior state, you make it possible for your exams are repeatable, can run in parallel and do not rely on one check working earlier than one other check.
Traditionally, one thing just like the community is especially onerous to make use of in exams as a result of what in case your check runs however you do not have a community connection, or what in case your check runs throughout a time the place the server that you just’re speaking to has an outage? Your exams would now fail regardless that there’s nothing fallacious along with your code. So that you wish to decouple your exams from the community in order that your exams turn out to be repeatable, impartial and run with out counting on some exterior server.
On this put up, I will discover two completely different choices with you.
One possibility is to easily mock out the networking layer completely. The opposite possibility makes use of one thing known as URLProtocol which permits us to take full management over the requests and responses within URLSession, which suggests we will really make our exams work and not using a community connection and with out eradicating URLSession from our exams.
Defining the code that we wish to check
In an effort to correctly work out how we’ll check our code, we must always in all probability outline the objects that we wish to check. On this case, I wish to check a reasonably easy view mannequin and networking pair.
So let’s check out the view mannequin first. This is the code that I wish to check for my view mannequin.
@Observable
class FeedViewModel {
var feedState: FeedState = .notLoaded
personal let community: NetworkClient
init(community: NetworkClient) {
self.community = community
}
func fetchPosts() async {
feedState = .loading
do {
let posts = strive await community.fetchPosts()
feedState = .loaded(posts)
} catch {
feedState = .error(error)
}
}
func createPost(withContents contents: String) async throws -> Put up {
return strive await community.createPost(withContents: contents)
}
}In essence, the exams that I wish to write right here would affirm that calling fetchPost would really replace my listing of posts as new posts turn out to be accessible.
Planning the exams
I’d in all probability name fetchPost to make it possible for the feed state turns into a price that I count on, then I’d name it once more and return completely different posts from the community, ensuring that my feed state updates accordingly. I’d in all probability additionally wish to check that if any error can be thrown throughout the fetching part, that my feed state will turn out to be the corresponding error kind.
So to boil that right down to an inventory, this is the check I’d write:
- Ensure that I can fetch posts
- Ensure that posts get up to date if the community returns new posts
- Ensure that errors are dealt with accurately
I even have the create put up operate, which is a bit bit shorter. It does not change the feed state.
What I’d check there may be that if I create a put up with sure contents, a put up with the offered contents is definitely what’s returned from this operate.
I’ve already carried out the networking layer for this view mannequin, so this is what that appears like.
class NetworkClient {
let urlSession: URLSession
let baseURL: URL = URL(string: "https://practicalios.dev/")!
init(urlSession: URLSession) {
self.urlSession = urlSession
}
func fetchPosts() async throws -> [Post] {
let url = baseURL.appending(path: "posts")
let (information, _) = strive await urlSession.information(from: url)
return strive JSONDecoder().decode([Post].self, from: information)
}
func createPost(withContents contents: String) async throws -> Put up {
let url = baseURL.appending(path: "create-post")
var request = URLRequest(url: url)
request.httpMethod = "POST"
let physique = ["contents": contents]
request.httpBody = strive JSONEncoder().encode(physique)
let (information, _) = strive await urlSession.information(for: request)
return strive JSONDecoder().decode(Put up.self, from: information)
}
}In a perfect world, I’d have the ability to check that calling fetchPosts on my community consumer is definitely going to assemble the proper URL and that it’ll use that URL to make a name to URLSession. Equally for createPost, I’d wish to make it possible for the HTTP physique that I assemble is legitimate and comprises the information that I intend to ship to the server.
There are primarily two issues that we may wish to check right here:
- The view mannequin, ensuring that it calls the proper features of the community.
- The networking consumer, ensuring that it makes the proper calls to the server.
Changing your networking layer with a mock for testing
A standard strategy to check code that depends on a community is to easily take away the networking portion of it altogether. As an alternative of relying on concrete networking objects, we’d rely on protocols.
Abstracting our dependencies with protocols
This is what that appears like if we apply this to our view mannequin.
protocol Networking {
func fetchPosts() async throws -> [Post]
func createPost(withContents contents: String) async throws -> Put up
}
@Observable
class FeedViewModel {
var feedState: FeedState = .notLoaded
personal let community: any Networking
init(community: any Networking) {
self.community = community
}
// features are unchanged
}The important thing factor that modified right here is that as an alternative of relying on a community consumer, we rely on the Networking protocol. The Networking protocol defines which features we will name and what the return sorts for these features will likely be.
For the reason that features that we have outlined are already outlined on NetworkClient, we will replace our NetworkClient to evolve to Networking.
class NetworkClient: Networking {
// No modifications to the implementation
}In our utility code, we will just about use this community consumer passage to our feed view mannequin and nothing would actually change. It is a actually low-key strategy to introduce testability into our codebase for the feed view mannequin.
Mocking the community in a check
Now let’s go forward and write a check that units up our feed view mannequin in order that we will begin testing it.
class MockNetworkClient: Networking {
func fetchPosts() async throws -> [Post] {
return []
}
func createPost(withContents contents: String) async throws -> Put up {
return Put up(id: UUID(), contents: contents)
}
}
struct FeedViewModelTests {
@Check func testFetchPosts() async throws {
let viewModel = FeedViewModel(community: MockNetworkClient())
// we will now begin testing the view mannequin
}
}Now that we’ve a setup that we will check, it is time to take one other have a look at our testing objectives for the view mannequin. These testing objectives are what is going on to drive our choices for what we’ll put in our MockNetworkClient.
Writing our exams
These are the exams that I needed to write down for my put up fetching logic:
- Ensure that I can fetch posts
- Ensure that posts get up to date if the community returns new posts
- Ensure that errors are dealt with accurately
Let’s begin including them one-by-one.
In an effort to check whether or not I can fetch posts, my mock community ought to in all probability return some posts:
class MockNetworkClient: Networking {
func fetchPosts() async throws -> [Post] {
return [
Post(id: UUID(), contents: "This is the first post"),
Post(id: UUID(), contents: "This is post number two"),
Post(id: UUID(), contents: "This is post number three")
]
}
// ...
}With this in place, we will check our view mannequin to see if calling fetchPosts will really use this listing of posts and replace the feed state accurately.
@Check func testFetchPosts() async throws {
let viewModel = FeedViewModel(community: MockNetworkClient())
await viewModel.fetchPosts()
guard case .loaded(let posts) = viewModel.feedState else {
Concern.document("Feed state just isn't set to .loaded")
return
}
#count on(posts.depend == 3)
}The second check would have us name fetchPosts twice to make it possible for we replace the listing of posts within the view mannequin.
To ensure that us to manage our exams absolutely, we must always in all probability have a strategy to inform the mock community what listing of posts it ought to return after we name fetchPost. Let’s add a property to the mock that permits us to specify an inventory of posts to return from inside our exams:
class MockNetworkClient: Networking {
var postsToReturn: [Post] = []
func fetchPosts() async throws -> [Post] {
return postsToReturn
}
func createPost(withContents contents: String) async throws -> Put up {
return Put up(id: UUID(), contents: contents)
}
}And now we will write our second check as follows:
@Check func fetchPostsShouldUpdateWithNewResponses() async throws {
let consumer = MockNetworkClient()
consumer.postsToReturn = [
Post(id: UUID(), contents: "This is the first post"),
Post(id: UUID(), contents: "This is post number two"),
Post(id: UUID(), contents: "This is post number three")
]
let viewModel = FeedViewModel(community: consumer)
await viewModel.fetchPosts()
guard case .loaded(let posts) = viewModel.feedState else {
Concern.document("Feed state just isn't set to .loaded")
return
}
#count on(posts.depend == 3)
consumer.postsToReturn = [
Post(id: UUID(), contents: "This is a new post")
]
await viewModel.fetchPosts()
guard case .loaded(let posts) = viewModel.feedState else {
Concern.document("Feed state just isn't set to .loaded")
return
}
#count on(posts.depend == 1)
}The check is now extra verbose however we’re in full management over the responses that our mock community will present.
Our third check for fetching posts is to make it possible for errors are dealt with accurately. Which means that we must always apply one other replace to our mock. The purpose is to permit us to outline whether or not our name to fetchPosts ought to return an inventory of posts or throw an error. We will use Consequence for this:
class MockNetworkClient: Networking {
var fetchPostsResult: Consequence<[Post], Error> = .success([])
func fetchPosts() async throws -> [Post] {
return strive fetchPostsResult.get()
}
func createPost(withContents contents: String) async throws -> Put up {
return Put up(id: UUID(), contents: contents)
}
}Now we will make our fetch posts calls succeed or fail as wanted within the exams. Our exams would now have to be up to date in order that as an alternative of simply passing an inventory of posts to return, we’ll present success with the listing. This is what that might appear to be for our first check (I’m positive you may replace the longer check based mostly on this instance).
@Check func testFetchPosts() async throws {
let consumer = MockNetworkClient()
consumer.fetchPostsResult = .success([
Post(id: UUID(), contents: "This is the first post"),
Post(id: UUID(), contents: "This is post number two"),
Post(id: UUID(), contents: "This is post number three")
])
let viewModel = FeedViewModel(community: consumer)
await viewModel.fetchPosts()
guard case .loaded(let posts) = viewModel.feedState else {
Concern.document("Feed state just isn't set to .loaded")
return
}
#count on(posts.depend == 3)
}Information that we will present successful or failure for our exams. We will really go on forward and inform our exams to throw a selected failure.
@Check func fetchPostsShouldUpdateWithErrors() async throws {
let consumer = MockNetworkClient()
let expectedError = NSError(area: "Check", code: 1, userInfo: nil)
consumer.fetchPostsResult = .failure(expectedError)
let viewModel = FeedViewModel(community: consumer)
await viewModel.fetchPosts()
guard case .error(let error) = viewModel.feedState else {
Concern.document("Feed state just isn't set to .error")
return
}
#count on(error as NSError == expectedError)
}We now have three exams that check our view mannequin.
What’s attention-grabbing about these exams is that all of them rely on a mock community. Which means that we’re not counting on a community connection. However this additionally does not imply that our view mannequin and community consumer are going to work accurately.
We’ve not examined that our precise networking implementation goes to assemble the precise requests that we count on it to create. In an effort to do that we will leverage one thing known as URLProtocol.
Mocking responses with URLProtocol
Figuring out that our view mannequin works accurately is absolutely good. Nonetheless, we additionally wish to make it possible for the precise glue between our app and the server works accurately. That implies that we must be testing our community consumer in addition to the view mannequin.
We all know that we should not be counting on the community in our unit exams. So how can we get rid of the precise community from our networking consumer?
One method could possibly be to create a protocol for URLSession and stuff the whole lot out that manner. It is an possibility, however it’s not one which I like. I a lot favor to make use of one thing known as URLProtocol.
Once we use URLProtocol to mock out our community, we will inform URLSession that we must be utilizing our URLProtocol when it is attempting to make a community request.
This permits us to take full management of the response that we’re returning and it implies that we will make it possible for our code works without having the community. Let’s check out an instance of this.
Earlier than we implement the whole lot that we want for our check, let’s check out what it appears to be like wish to outline an object that inherits from URLProtocol. I am implementing a few fundamental strategies that I’ll want, however there are different strategies accessible on an object that inherits from URLProtocol.
I extremely suggest you check out Apple’s documentation for those who’re focused on studying about that.
Establishing ur URLProtocol subclass
For the exams that we have an interest implementing, that is the skeleton class that I will be working from:
class NetworkClientURLProtocol: URLProtocol {
override class func canInit(with request: URLRequest) -> Bool {
return true
}
override class func canonicalRequest(for request: URLRequest) -> URLRequest {
return request
}
override func startLoading() {
// we will carry out our faux request right here
}
}Within the startLoading operate, we’re alleged to execute our faux community name and inform the consumer (which is a property that we inherit from URLProtocol) that we completed loading our information.
So the very first thing that we have to do is implement a manner for a consumer of our faux community to supply a response for a given URL. Once more, there are lots of methods to go about this. I am simply going to make use of probably the most fundamental model that I can provide you with to make it possible for we do not get slowed down by particulars that can differ from mission to mission.
struct MockResponse {
let statusCode: Int
let physique: Information
}
class NetworkClientURLProtocol: URLProtocol {
// ...
static var responses: [URL: MockResponse] = [:]
static var validators: [URL: (URLRequest) -> Bool] = [:]
static let queue = DispatchQueue(label: "NetworkClientURLProtocol")
static func register(
response: MockResponse, requestValidator: @escaping (URLRequest) -> Bool, for url: URL
) {
queue.sync {
responses[url] = response
validators[url] = requestValidator
}
}
// ...
}By including this code to my NetworkClientURLProtocol, I can register responses and a closure to validate URLRequest. This permits me to check whether or not a given URL ends in the anticipated URLRequest being constructed by the networking layer. That is significantly helpful once you’re testing POST requests.
Word that we have to make our responses and validators objects static. That is as a result of we will not entry the precise occasion of our URL protocol that we’ll use earlier than the request is made. So we have to register them statically after which in a while in our begin loading operate we’ll pull out the related response invalidator. We have to make it possible for we synchronize this via a queue so we’ve a number of exams working in parallel. We would run into points with overlap.
Earlier than we implement the check, let’s full our implementation of startLoading:
class NetworkClientURLProtocol: URLProtocol {
// ...
override func startLoading() {
// be sure that we're good to...
guard let consumer = self.consumer,
let requestURL = self.request.url,
let validator = validators[requestURL],
let response = responses[requestURL]
else {
Concern.document("Tried to carry out a URL Request that does not have a validator and/or response")
return
}
// validate that the request is as anticipated
#count on(validator(self.request))
// assemble our response object
guard let httpResponse = HTTPURLResponse(
url: requestURL,
statusCode: response.statusCode, httpVersion: nil,
headerFields: nil
) else {
Concern.document("Not capable of create an HTTPURLResponse")
return
}
// obtain response from the faux community
consumer.urlProtocol(self, didReceive: httpResponse, cacheStoragePolicy: .notAllowed)
// inform the URLSession that we have "loaded" information
consumer.urlProtocol(self, didLoad: response.physique)
// full the request
consumer.urlProtocolDidFinishLoading(self)
}
}The code comprises feedback on what we’re doing. When you may not have seen this type of code earlier than, it must be comparatively self-explanatory.
Implementing a check that makes use of our URLProtocol subclass
Now that we’ve bought startLoading carried out, let’s attempt to use this NetworkClientURLProtocol in a check…
class FetchPostsProtocol: NetworkClientURLProtocol { }
struct NetworkClientTests {
func makeClient(with protocolClass: NetworkClientURLProtocol.Kind) -> NetworkClient {
let configuration = URLSessionConfiguration.default
configuration.protocolClasses = [protocolClass]
let session = URLSession(configuration: configuration)
return NetworkClient(urlSession: session)
}
@Check func testFetchPosts() async throws {
let networkClient = makeClient(with: FetchPostsProtocol.self)
let returnData = strive JSONEncoder().encode([
Post(id: UUID(), contents: "This is the first post"),
Post(id: UUID(), contents: "This is post number two"),
Post(id: UUID(), contents: "This is post number three"),
])
let fetchPostsURL = URL(string: "https://practicalios.dev/posts")!
FetchPostsProtocol.register(
response: MockResponse(statusCode: 200, physique: returnData),
requestValidator: { request in
return request.url == fetchPostsURL
},
for: fetchPostsURL
)
let posts = strive await networkClient.fetchPosts()
#count on(posts.depend > 0)
}
}The very first thing I am doing on this code is creating a brand new subclass of my NetworkClientProtocol. The explanation I am doing that’s as a result of I may need a number of exams working on the identical time.
For that cause, I would like every of my Swift check features to get its personal class. This is perhaps me being a bit bit paranoid about issues overlapping when it comes to when they’re known as, however I discover that this creates a pleasant separation between each check that you’ve got and the precise URLProtocol implementation that you just’re utilizing to carry out your assertions.
The purpose of this check is to make it possible for once I ask my community consumer to go fetch posts, it really performs a request to the proper URL. And given a profitable response that comprises information in a format that’s anticipated from the server’s response, we’re capable of decode the response information into an inventory of posts.
We’re primarily changing the server on this instance, which permits us to take full management over verifying that we’re making the proper request and now have full management over regardless of the server would return for that request.
Testing a POST request with URLProtocol
Now let’s see how we will write a check that makes positive that we’re sending the proper request after we’re attempting to create a put up.
struct NetworkClientTests {
// ...
@Check func testCreatePost() async throws {
let networkClient = makeClient(with: CreatePostProtocol.self)
// arrange anticipated information
let content material = "It is a new put up"
let expectedPost = Put up(id: UUID(), contents: content material)
let returnData = strive JSONEncoder().encode(expectedPost)
let createPostURL = URL(string: "https://practicalios.dev/create-post")!
// register handlers
CreatePostProtocol.register(
response: MockResponse(statusCode: 200, physique: returnData),
requestValidator: { request in
// validate fundamental setup
guard
let httpBody = request.streamedBody,
request.url == createPostURL,
request.httpMethod == "POST" else {
Concern.document("Request just isn't a POST request or does not have a physique")
return false
}
// guarantee physique is appropriate
do {
let decoder = JSONDecoder()
let physique = strive decoder.decode([String: String].self, from: httpBody)
return physique == ["contents": content]
} catch {
Concern.document("Request physique just isn't a sound JSON object")
return false
}
},
for: createPostURL
)
// carry out community name and validate response
let put up = strive await networkClient.createPost(withContents: content material)
#count on(put up == expectedPost)
}
}There’s various code right here, however total it follows a reasonably comparable step to earlier than. There’s one factor that I wish to name your consideration to, and that’s the line the place I extract the HTTP physique from my request within the validator. As an alternative of accessing httpBody, I am accessing streamedBody. This isn’t a property that usually exists on URLRequest, so let’s discuss why I would like that for a second.
Whenever you create a URLRequest and execute that with URLSession, the httpBody that you just assign is transformed to a streaming physique.
So once you entry httpBody within the validator closure that I’ve, it is going to be nil.
As an alternative of accessing that, we have to entry the streaming physique, collect the information, and return alll information.
This is the implementation of the streamedBody property that I added in an extension to URLRequest:
extension URLRequest {
var streamedBody: Information? {
guard let bodyStream = httpBodyStream else { return nil }
let bufferSize = 1024
let buffer = UnsafeMutablePointer.allocate(capability: bufferSize)
var information = Information()
bodyStream.open()
whereas bodyStream.hasBytesAvailable {
let bytesRead = bodyStream.learn(buffer, maxLength: bufferSize)
information.append(buffer, depend: bytesRead)
}
bodyStream.shut()
return information
}
} With all this in place, I will now test that my community consumer constructs a completely appropriate community request that’s being despatched to the server and that if the server responds with a put up like I count on, I am really capable of deal with that.
So at this level, I’ve exams for my view mannequin (the place I mock out all the networking layer to make it possible for the view mannequin works accurately) and I’ve exams for my networking consumer to make it possible for it performs the proper requests on the appropriate instances.
In Abstract
Testing code that has dependencies is all the time a bit bit difficult. When you’ve gotten a dependency you will wish to mock it out, stub it out, take away it or in any other case conceal it from the code that you just’re testing. That manner you may purely check whether or not the code that you just’re focused on testing acts as anticipated.
On this put up we checked out a view mannequin and networking object the place the view mannequin relies on the community. We mocked out the networking object to make it possible for we may check our view mannequin in isolation.
After that we additionally needed to write down some exams for the networking object itself. To do this, we used a URLProtocol object. That manner we may take away the dependency on the server completely and absolutely run our exams in isolation. We will now check that our networking consumer makes the proper requests and handles responses accurately as effectively.
Which means that we now have end-to-end testing for a view mannequin and networking consumer in place.
I don’t typically leverage URLProtocol in my unit exams; it’s primarily in advanced POST requests or flows that I’m focused on testing my networking layer this deeply. For easy requests I are likely to run my app with Proxyman connected and I’ll confirm that my requests are appropriate manually.