To be honest.. writing unit tests in iOS is a myth. Usually iOS developers work for small startups, which source money from investors. It is important for those investors to create a product as soon as possible. Manuall tests or application stability? Who cares… It is our obligation as a professional developers we need to change this approach and teach our clients that development process consists of two inseparable elements -code & tests. If you want to learn more about this approach please check the book “The Software Craftsman: Professionalism, Pragmatism, Pride” (Robert C. Martin Series).

In this blogpost you will learn how to write unit tests of your network layer. After finishing you will see how simple it is. 👊

Before you start please fetch the latest changes from my repo because this tutorial is based on my previous post about Network Layer.

marcinjackowski/NetworkLayer

Quick and Nimble

You may wonder why did I choose Quick and Nimble instead of XCTest framework 🤔

The answer is simple - combination of those two libraries is simply, easy to use and you can define the expected behaviour in a more readable way. Quick is a testing framework while Nimble is a matching framework. If it’s your first time with both frameworks, check GitHub documentation where you can find many examples of use.

• Quick-https://github.com/Quick/Quick/blob/master/Documentation/en-us/README.md
• Nimble-https://github.com/Quick/Nimble

If you don’t understand these frameworks and don’t how to use them.. Don’t worry, just leave a comment and I will write a special blogpost about Quick and Nimble usage from the scratch 🍻

Last thing. In Quick framework there are four functions that describe tests: describe, context, it and fit. In my opinion these four don’t explain well when should they be used. To create tests that are more familiar and useful with general test representing style, create extension for Quick to transform this functions to Given, When, Then style. Check out the new syntax below:

• describe == given
• context == when
• it == then
• fit == onlyThen

Please create a new file QuickCustomAliases and copy those lines:

As you can see, new functions better illustrate their usage and show the way how to construct tests.

ServiceMock

ProviderProtocol has one function request which takes two parameters: type and service. If your provider is parsing response properly, at first you have to create service mock and then example model with a simple structure to test.

Create new file ServiceMock and copy following code:

1. This service has four cases to test the most common things:
   1. jsonResponseWith200 -send plain request with json encoding. Expectations: status code 200.
   2. jsonResponseWithURLParametersWith200- send request with parameters with json encoding. Expectations: status code 200.
   3. errorWith500- Expectations: error with status code 500.
2. Base url cannot be empty because string url must be valid. If it is empty — the app will crash.
3. It is only a mock so you can write path you want.

ServiceModel

One of the ServiceMock cases return json data in response. It would be great to write tests of module responsibles for encoding json data. To do that, it’s necessary to create mock model which conforms to Codable and Equatable. Create new file ModelMock:

URLSessionDataTaskProtocol

Before you start writing tests you have to modify current implementation of NetworkLayer just a bit. In version from previous blogpost, request function of URLSessionProtocol returns URLSessionDataTask 🤔 And that is a problem. In our test case you want to simulate resume task and return mock instead of real object. To do that create URLSessionDataTaskProtocol file and copy following code:

As you can see this protocol contains only one function resume. In this particular case it’s enough, but in case when you want to cancel or pause task it’s easy to extend the protocol with new variants. Moreover URLSessionDataTaskProtocol must be an extension of URLSessionDataTask.

Next you need to change return value of request function from URLSessionProtocol to URLSessionDataTaskProtocol.

At the end you need to create mock which conforms to URLSessionDataTaskProtocol. You may wonder why? I will explain in in a later paragraph.

URLSessionProviderSpec

If you have already created ServiceMock and ServiceModel now it’s time to start testing! URLSessionProvider is the most important file of network layer. To write first test please create the file URLSessionProvider with suffix Spec. Every file which conforms to QuickSpec must contain this suffix.

URLSessionProvider tests

If you look at the function request of URLSessionProvider you can see that in the second line of this function, session is calling dataTask to send request. So let’s create our first test:

💏 When: Request is called, 👶 Then: Session should call dataTask.

You may wonder how do we know if session has called function dataTask? SessionProtocol doesn’t have any properties called dataTask, only function dataTask 🤔 That’s why we love dependency inversion which is helpful in testing objects. Let’s create a new file URLSessionMock which conforms to URLSessionProtocol.

As you can see you have added new property isDataTaskCalled with initial value false. If session call function dataTask you should change this property to true which means that this function was called. Furthermore to test URLSession you can’t return “real” URLSessionProtocol’s object so in init you should pass mock object and return this object in dataTask function. It’s time to complete first test and write first assertion.

CMD + U ⏲️ TADA! You wrote your first test!

Next test

In the same scope, it would be a good idea to write another test to check if url was set properly.

💏 When: Request is called, 👶 Then: Request should set proper url.

This test also checks our extension to URLRequest for building request from ServiceProtocol. Add lastURL property to URLSessionMock and assign url from request property.

New test will be easy to write.

CMD + U ⏲️ Test succeeded!

Next Test

As you can see URLSessionProtocol returns URLSessionDataTaskProtocol.Can you guess what kind of test will be next? 🤔 Of course 🎊 Check if resume function was called!

💏 When: Request is called, 👶 Then: URLSessionTask should call resume function.

Error: Value of type ‘URLSessionDataTaskMock’ has no member “isResumeCalled” 🤔

Do you know what to do?

CMD + U ⏲️ Test succeeded!

Next test

💏 When: Request is called with json response, status code 200, 👶 Then: Request should complete with success.

Info: Before you start, please copy NetworkResponseMatchers file from my repo. This file is needed to facilitate compare enum cases.

This example is much more complicated than previous one but i will explain it step by step how to write a test. In this case we want to get response with status code 200 and parse json to get ModelMock object. First we need to modify URLSessionMock. Add new property:

This property will be set from URLSessionProviderSpec and will information about tested case (for example .jsonResponseWith200). Additionally add this following function inside dataTask:

This few lines switch over particular service and do some jobs. dataTask function has completionHandler which returns (Data?, URLResponse?, Error?). In .jsonResponseWith200 you need to do three things:

1. Create ModelMock object with test value.
2. Encode this object.
3. Create response with status code 200.
4. Call completion handler with just created parameters.

Let’s get back to URLSessionProviderSpec. What to do next? Create a new when closure, then set service case to .jsonResponseWith200.

As you can see there is no response property. Add this property under spec function with type NetworkResponse<ModelMock>!. This property will keep information about response.

CMD + U ⏲️ Test succeeded!

Next test

💏 When: Request is called with json response and status code 200, 👶 Then: Should return given model

CMD + U ⏲️ Test succeeded!

Homework

It’s your turn now!

You just wrote a few tests. I hope you understand how to write unit tests for NetworkLayer and if you do — it’s time to practice. Please try to write some extra tests as your homework.

1. 💏 When: Request is called when server is down (500), 👶 Then: Request should complete with failure response
2. 💏 When: Request is called with bad request (400), 👶 Then: Request should complete with failure response
3. 💏 When: Request is called with json response, URL parameters, status code 200, 👶 Then: HttpBody shoud be empty
4. 💏 When: Request is called with json response, URL parameters, status code 200, 👶 Then: URL should contains parameters
5. 💏 When: Request is called with json response, URL parameters, status code 200, 👶 Then: Request should complete with success response
6. 💏 When: Request is called with json response, URL parameters, status code 200, 👶 Then: Request should return given model

If you are having some problems with those exercises check my repo. Or write me a private message on Twitter @mtc_jackowski.

marcinjackowski/UnitTestNetworkLayer

Unit test Network Layer was originally published in thecocoapps on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dependency inversion is the last letter of SOLID therm. Last position doesn’t mean less important than the other, in my opinion this principle is the most important software design pattern.

The general idea of this principle is as simple as it is important:

High-level modules, which provide complex logic, should be easily reusable and unaffected by changes in low-level modules, which provide utility features.

In simple words — we shouldn’t use class name in any function and variable declaration. Instead of this, we should use protocols or abstract class.

Based on this idea, Robert C. Martin’s definition of the Dependency Inversion Principle consists of two parts:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend on details. Details should depend on abstractions.

If it’s your first time with DI you probably don’t understand those sentences because it sounds incomprehensible. Don’t worry! In next step i will show you the difference between traditional and inversion dependency.

Traditional dependency

Imagine that you have to implement screen in your app to fetch user friends from API. In traditional way you will create some service and add property to the class. Example:

Congrats!🙌🏻 Project manager and client are happy. But in one day requirements are changing. You have to change logic of fetch friends from API to database (CoreData) 🤔.

The service variable is of a concrete type SpecificReceiver and you invoke service method directly. This means the high level Profile depends on the low level FriendsService.

Why is this bad? Because if you were to change the FriendsService, you would have to change the Profile as well.

So how to change the code to conform to dependency inversion principle? Let’s move to the next step.

Dependency inversion

To design this approach we have to start with an abstraction. You have to create protocol which service to fetch friends from API or database conform.

Let’s redesign Profile class.

In this scenario Profile class depends on the FriendsWorker protocol not on a concrete type FriendsService. This approach give you the opportunity to change logic without changing code in Profile class! That's awesome. If you want to fetch friends list form API, create FriendsService class conform to FriendsWorker protocol and inject this object to Profile init! What about fetch friends from Database? How to do it? In the same way!

The following diagram presents the dependency inversion. Each service or database just needs to conform to the FriendsWorker protocol in order to be used by Profile.

That’s it. Thanks for being awesome. Please leave a comment below. Clap if you liked it ✌🏻

marcinjackowski (Marcin Jackowski)

Dependency Inversion Swift was originally published in thecocoapps on Medium, where people are continuing the conversation by highlighting and responding to this story.

My answer for this question is — Use pure Swift without any third-party libraries. It’s a super simple to implement protocol-oriented layer, type safe with enum to configure endpoints and fully testable, of course. In these few points you will learn how to write protocol oriented networking layer that you can customise.

First things first

Before you start, it’s important to understand URLSessionand its constituent classes. In general URLSession is responsible for sending and receivng HTTPRequests. For basic requests you can use sharedsession which has no configuration object. It’s not as customisable as sessions you create by yourself, but it serves good starting point if you have very limited requirements. For other kinds of sessions, you instantiate a URLSessionwith one of three kinds of configurations:

1. .default - session behaves as a shared session, but allows more configuration and to obtain data incrementally with a delegate.
2. .ephemeral - session is also similar to shared session, but don’t write caches, cookies, or credentials to disk.
3. .background - session let you perform uploads and downloads of content in the background while your app isn't running.

URLSession returns data in two ways:

1. completion handler
2. calling methods on a delegate

Within a session you can create URLSessionTask to retrieve data from the server, upload photos or download files. Moreover you can also resume, suspend and cancel tasks. URLSessionTask gives opportunity to pause running task for example when user leaves app and resume it when returns. The URLSession provides three types of tasks:

1. data - sends and receives data using Data objects. Data tasks are intended for short, often interactive requests to a server.
2. upload - similar to data tasks, but in general used to upload files and support background uploads while the app isn’t running.
3. download - retrieve data in the form of a file and support background downloads and uploads while the app isn’t running.

In this tutorial you will use only first type of URLSessionTask to send request and handle response form the server.

Ok after a short recap of what URLSession can do and now let's do some practice.

ServiceProtocol

First you have to divide network layer to a small services. Keeping all requests in one class/enum is difficult to maintain and might transform into a monster massive thing. ServiceProtocol will be helper to create URLRequest. ServiceProtocol contains constituent components such as baseURL, path, method, headers, task and parametersEncoding. Go ahead and create your first file of simple networking layer.

HTTPMethod is an enum responsible for setting HTTP method of requests. URLRequest has property .httpMethod to set method String type.

Task is an enum responsible for configuring parameters for a specific service. You can add as many cases as are applicable to your network layer requirements. For example upload(Data), download(parameters: Parameters) etc. Example has only two cases to send plain request or with parameters.

ParametersEncoding

ParametersEncoding is an enum responsible for setting encoding type. In this example you have to use the most popular: URL and JSON.

Voilà! First part of creating network layer is done. Keep your head up and keep going! Let’s move to the next part — How to implement constructor of URLRequest.

Request

Before you send first request to the API you have to create custom request from ServiceProtocol. As you probably noticed Service has all information to construct Request. To avoid creating new class you will create an extension to URLRequest and URLComponents.

First of all: create URLComponents file. This extension will merge baseURL with path and will add parameters to the url if parameters encoding is url. Paste this code to your file:

1. To get full path of url you need to append path to base url..
2. Using your new url, you initialise a URLComponents.
3. If parameters encoding is “url” and request has parameters — create array of [URLQueryItem] for each parameter and set to the queryItems.

Next step is URLRequest. Create file and add the following implementation:

1. First create urlComponents.
2. Using your new urlComponents initialise a URLRequest.
3. Set httpMethod of the request equal to that of our ServiceProtocol.
4. Set headers.
5. If parameters encoding is “json” and request has parameters — use JSONSerialization to covert dictionary with parameters to Data. You can add try catch closure to handle the exception.

Next part done! Congratulations!

NetworkResponse

When you get response from sent request, completion handler returns unreadable information. Optional data, response and error says nothing. You have to create enum to handle response from API and display clear message. Create two files NetworkResponse and NetworkError. There are two cases:

1. .success - if success - returns Decodable model
2. .error - if error - returns error of type NetworkError.

For blogpost example NetworkError has only two cases:

URLSession

You have almost finished network layer. Last thing which need to be implement is a provider to send requests. To do that create new file ProviderProtocol and add the following implementation:

ATTENTION!: T must conform to Decodable protocol.

If ProviderProtocol is done, now you can start implementing last class URLSessionProvider which is the heart of your network layer. To do that: create new file and copy following code:

1. URLSessionProvider conforms to ProviderProtocol which has been created few lines earlier.
2. This approach is necessary to test network layer. It’s essential because in easy way you can switch session with mock file and simulate responses from API without internet connection. With the next blogpost i will explain you how to test network layer. For now please create a new file URLSessionProtocol and copy following code:

Next you will create request function. This function is responsible for all the vital work in our network layer. Add this method to URLSessionProvider.

1. Initialise request from service object.
2. Create URLSessionDataTask to send and receive data from API. Data tasks are intended for short, often interactive requests to a server.
3. Start task. Session will send request to the server and wait for the response.
4. handleDataResponse completionHandler returns optional values and you actually don't know if request has finished with success or error. You need extra method to parse response data and error.

1. First you have to check if an error has occurred. If your API return some information in error, add custom init to the NetworkError enum and parse it.
2. In this scenario all requests return a json data so if response is empty function returns error
3. HTTPURLResponse contains status code of sent request. In this example requests with status code between 200...299 have success status in other cases failure.
4. Use JSONDecoder to decode response data and return expected object with type T.

That’s all! Your network layer is completed in pure Swift, no third party libraries. In next part you will find out how to create simple service and send first request.

Demo

In this demo you will use free API (https://jsonplaceholder.typicode.com) which allows to fetch posts, comments and users info. First of all create file PostService and copy following code:

PostService implements two cases: fetch all posts and comments for specific postId. For both cases you use “GET” method and “url” parameters encoding. Case “all” doesn’t require any special parameters so you can use plain request but for “comments” case you need to send request with parameters (key: “postId”, value: Int).

Finally you are ready to send your first request and use implemented provider! Open ViewController and add the following method:

1. Create property to have strong reference to the provider.
2. Send request with specific type. In this case you want to fetch list of posts so add Post model which conforms to Decodable and Encodable protocol.

3. Handle response! That’s all! :)

You can download the complete project for this tutorial here:

marcinjackowski/NetworkLayer

Conclusion

As you can see to build networking layer it’s not necessary to use third-party library with complicated logic. The biggest advantage of this solution is that it’s written in pure swift. To You can download the complete project for this tutorial here.

Network Layer in Swift 4.0 was originally published in thecocoapps on Medium, where people are continuing the conversation by highlighting and responding to this story.