Let’s imagine you have a small project, where you used to deliver new features in just 2 days. Then your project grows bigger. The delivery date becomes uncontrollable, from 2 days to 1 week, then 2 weeks. It drives you crazy! You keep complaining: a good product shouldn’t be so complicated! That’s exactly what I have faced and it was really a bad time for me. Now, after working for a few years in this area, cooperating with many excellent engineers, I realized that the product design doesn’t really make the code so complex. It’s me who makes it so complicated.

We could have the experience writing spaghetti code which significantly hurts the performance of our projects.The question is how can we fix it? A good architecture pattern might help. In this article, we are going to talk about one of the good architecture: Model-View-ViewModel (MVVM). MVVM is a trending iOS architecture that focuses on the separation of development of user interface from development of the business logic.

The term “good architecture” may sound way too abstract. It’s also difficult to know where to start. Here’s a tip: Instead of focusing on the definition of the architecture, we can focus on how to improve the testability of the code. There’re so many software architectures, such as MVC, MVP, MVVM, VIPER, It’s clear, we might not be able to master all of those architectures. However, we are still able to keep a simple rule in mind: no matter what architecture we decide to use, the ultimate goal is to make test simpler. Using this approach we start thinking before writing code. We put emphasis on how to separate responsibility intuitively. Moreover, the design of the architecture seems clear and reasonable with this mindset, we won’t stuck in trivial details anymore

TL;DR

In this article, you will learn:

• The reason we choose the MVVM over the Apple MVC
• How to adapt MVVM to design a clearer architecture
• How to write a simple real-world app based on the MVVM

You won’t see:

• The comparison between MVVM, VIPER, Clean, etc
• A silver bullet that will solve all problems

All of those architectures have the pros and the cons, but they are all designed to make the code simpler and clearer. So we decided to focus on why we select MVVM over MVC and how we move from MVC to MVVM. If you are interested in the cons of MVVM, please refer to the discussion at the end of this article.

So let’s start!

Apple MVC

MVC (Model-View-Controller) is Apple’s recommended architectural pattern. The definition could be found here. The interaction between objects in the MVC is depicted as the following figure:

In iOS/MacOS development, due to the introduction of the ViewController, it usually becomes:

The ViewController contains the View and owns the Model. The problem is we used to write the controller code as well as the view code in the ViewController. It makes the ViewController too complex. That’s why we called it a Massive View Controller. While writing a test for the ViewController, you need to mock the view and the life cycle of it. But views are difficult to be mocked. And we actually don’t want to mock the view if we only want to test the controller logic. All these things make writing tests so complicated.

So the MVVM is here to rescue.

MVVM — Model — View — ViewModel

MVVM is proposed by John Gossman in 2005. The main purpose of the MVVM is to move the data state from the View to the ViewModel. The data flow in MVVM could be drawn as the following figure:

According to the definition, the View consists of only visual elements. In the View, we only do things like layout, animation, initializing UI components, etc. There’s a special layer between the View and the Model called the ViewModel. The ViewModel is a canonical representation of the View. That is, the ViewModel provides a set of interfaces, each of which represents a UI component in the View. We use a technique called “binding” to connect UI components to ViewModel interfaces. So, in MVVM, we don’t touch the View directly, we deal with business logic in the ViewModel and thus the View changes itself accordingly. We write presentational things such as converting Date to String in the ViewModel instead of the View. Therefore, it becomes possible to write a simpler test for the presentational logic without knowing the implementation of the View.

Let’s go back and take a higher look at the figure above. In general, the ViewModel receives the user interaction from the View, fetches data from the Model, then process the data to a set of ready-to-display properties. The View updates itself after observing the change of the ViewModel. That’s the whole story of the MVVM.

Specifically, for MVVM in iOS development, the UIView/UIViewController represent the View. We only do:

1. Initiate/Layout/Present UI components.
2. Bind UI components with the ViewModel.

On the other hand, in the ViewModel, we do:

1. Write controller logics such as pagination, error handling, etc.
2. Write presentational logic, provide interfaces to the View.

You might notice that the ViewModel is kinda complex. In the end of this article, we will discuss the bad part of the MVVM. Anyway, for a medium sized project, the MVVM is still a good choice to eat an elephant one bite at a time!

In the following sections, we are going to write a simple app with MVC pattern and then describe how to refactor the app to the MVVM pattern. The sample project with unit tests could be found on my GitHub:

koromiko/Tutorial

Tutorial - Code for https://koromiko1104.wordpress.com

github.com

Let’s start!

A simple gallery app — MVC

We are going to write a simple app, in which:

1. The app fetches popular photos from 500px API and lists photos in a UITableView.
2. Each cell in the table view shows a title, a description and the created date of a photo.
3. Users are not allowed to click photos which are not labeled for_sale.

In this app, we have a struct named Photo, it represents a single photo. Here’s the interface of the Photo class:

The initial view controller of the app is a UIViewController containing a table view called PhotoListViewController. We fetch Photo objects through the APIService in the PhotoListViewController, and reload the table view after photos are fetched:

The PhotoListViewController is also a datasource of the table view:

In the func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell, we select the corresponding Photo object and assign the title, description, and the date to a cell. Since the Photo.date is a Date object, we have to convert it to a String using a DateFormatter.

The following code is the implementation of the table view delegate:

We select the corresponding Photo object in func tableView(_ tableView: UITableView, willSelectRowAt indexPath: IndexPath) -> IndexPath?, check the for_sale property. If it’s true, save the selectedIndexPath for a segue. If not, display an error message and return nil to prevent segueing.

The source code of PhotoListViewController could be found here, please refer to the tag “MVC”.

So what’s wrong with the code above? In the PhotoListViewController, we can find the presentational logic such as converting Date to String and when to start/stop the activity indicator. We also have the View code such as the implementation of showing/hiding the table view. In addition, there’s another dependency, the API service, in the view controller. If you plan to write tests for the PhotoListViewController, you will find that you’re stuck since it’s too complicated. We have to mock the APIService, mock the table view and mock the cell to test the whole PhotoListViewController. Phew!

Remember that we want to make writing tests easier? Let’s try MVVM approach!

Try MVVM

In order to solve the problem, our first priority is to clean up the view controller, split the view controller into two parts: the View and the ViewModel. To be specific, we are going to:

1. Design a set of interfaces for binding.
2. Move the presentational logic and controller logic to the ViewModel.

First thing first, let’s take a look at the UI components in the View:

1. activity Indicator (loading/finish)
2. tableView (show/hide)
3. cells (title, description, created date)

So we can abstract the UI components to a set of canonical representations:

Each UI component has a corresponding property in the ViewModel. We can say that what we will see in the View should be the same as what we see in the ViewModel.

But how do we do the binding?

Implement the Binding with Closure

In Swift, there are various ways to achieve the “binding”:

1. Use KVO (Key-Value Observing) pattern.
2. Use 3rd party libraries for FRP (Functional Reactive Programming) such as RxSwift and ReactiveCocoa.
3. Craft it yourself.

Using the KVO pattern isn’t a bad idea, but it might create a huge delegate method and we have to be careful about the addObserver/removeObserver, which might be a burden to the View. The ideal way for binding is to use the binding solution in FRP. If you are familiar with functional reactive programming then go for it! If not, I wouldn’t recommend using FRP just for binding because it’s kind of confusing to crack a nut using a sledgehammer. Here is a brilliant article talking about using the decorator pattern to craft the binding yourself. In this article, we are going to put things simpler. We bind things using a closure. Practically, in the ViewModel an interface/property for binding looks like this:

On the other hand, in the View, we assign a closure to the propChanged as a callback closure for value updates.

Every time the property prop is updated, the propChanged is called. So we are able to update the View according to the change of the ViewModel. Quite straightforward, right?

Interfaces for binding in ViewModel

Now, let’s start to design our ViewModel, the PhotoListViewModel. Given the following three UI components:

1. tableView
2. cells
3. activity indicator

We create the interfaces/properties for binding in the PhotoListViewModel:

Each PhotoListCellViewModel object forms a canonical representation of a cell in the table view. It provides data interfaces for rendering a UITableView cell. We put all PhotoListCellViewModel objects into an array cellViewModels, the number of cells is exactly the number of items in that array. We can say that the array, cellViewModels, represents the table view. Once we update the cellViewModels in ViewModel, the closure reloadTableViewClosure will be called and the View updates correspondingly.

A single PhotoListCellViewModel looks like this:

As you can see, the properties of the PhotoListCellViewModel provide interface for binding to UI components in the View.

Bind the View with the ViewModel

With the interfaces for binding, now we’ll focus on the View part. First, in the PhotoListViewController, we initialize callback closures in viewDidLoad:

Then we are going to refactor the datasource. In MVC pattern, we setup presentational logics in the func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell, now we have to move the presentation logic to the ViewModel. The refactored datasource looks like:

The data flow now becomes:

1. The PhotoListViewModel starts to fetch data.
2. After the data fetched, we create PhotoListCellViewModel objects and update the cellViewModels.
3. The PhotoListViewController is notified of the update and then layouts cells using the updated cellViewModels.

It could be depicted as the following figure:

Dealing with user interaction

Let’s move on to the user interaction. In the PhotoListViewModel, we create a function:

When the user clicks on a single cell, the PhotoListViewController notifies the PhotoListViewModel using this function. So we can refactor the delegate method in PhotoListViewController:

It means that once the func tableView(_ tableView: UITableView, willSelectRowAt indexPath: IndexPath) -> IndexPath? was called due to a user interaction, the action is passed to the PhotoListViewModel. The delegate function decides whether to segue or not based on the property isAllowSegue provided by the PhotoListViewModel. We successfully remove the state from the View. 🍻

The Implementation of the PhotoListViewModel

It’s a long journey, right? Bear with me, we are touching the core of the MVVM! In the PhotoListViewModel, we have an array named cellViewModels, which represents the table view in the View.

How do we fetch data and get the array ready? We actually do two things in the initialization of the ViewModel:

1. Inject the dependency: the APIService
2. Fetch data using the APIService

In the code snippet above, we set the property isLoading to true before starting to fetch the data from the APIService. Thanks to the binding we did before, set the isLoading to true means that the View will switch the active indicator on. In the callback closure of the APIService, we process the fetched photo models and set the isLoading to false. We don’t need to touch the UI component directly, but it’s clear that the UI components work as what we expected when we changed those properties of the ViewModel.

Then here’s the implementation of the processFetchedPhoto( photos: [Photo] ) :

It does a simple job, wrapping the photo models into an array of PhotoListCellViewModel. When the property, cellViewModels, is updated the table view in the View reloads correspondingly.

Yay, we crafted the MVVM 🎉

The sample app could be found on my GitHub:

koromiko/Tutorial

Tutorial - Code for https://koromiko1104.wordpress.com

github.com

You might want to try the MVC version (tag: MVC) and then the MVVM one (the latest commit)

Recap

In this article, we successfully converted a simple app from the MVC pattern to the MVVM pattern. And we:

• Made a binding theme using the closure.
• Removed all controller logic from the View.
• Created a testable ViewModel.

Discussion

As I mentioned above, architectures all have the pros and the cons. After reading my article, you must have some ideas about what’s the cons of the MVVM. There are good articles talking about the bad parts of the MVVM, such as:

MVVM is Not Very Good — Soroush Khanlou
The Problems with MVVM on iOS — Daniel Hall

My biggest concern about MVVM is the ViewModel does too many things. As I mentioned in this article, we have the controller and the presenter in the ViewModel. Also, two roles, the builder and the router, are not included in the MVVM pattern. We used to put the builder and the router in the ViewController. If you’re interested in a clearer solution, you might want to check the MVVM+FlowController (Improve your iOS Architecture with FlowControllers) and two well-known architecture, VIPER and Clean by Uncle Bob.

Start small

There’s always a better solution. As professional engineers, we’re always learning how to improve the code quality. Developers like me were used to be overwhelmed by so many architectures and don’t know how to start writing unit tests. So the MVVM is a good place to begin your journey. It’s simple and the testability is still good. In another Soroush Khanlou’s article, 8 Patterns to Help You Destroy Massive View Controller, there are many good patterns and some of them are also adopted by the MVVM. Instead of being hampered by a gigantic architecture, how about we start writing test with small yet powerful MVVM pattern?

“The secret to getting ahead is getting started.” — Mark Twain

In the next article, I will continue to talk about writing unit tests for our simple gallery app. Stay tuned!

If you have any questions please don’t hesitate to leave a comment. Any kind of discussion is also welcome! Thank you for your attention.

References

Introduction to Model/View/ViewModel pattern for building WPF apps — John Gossman
Introduction to MVVM — objc
iOS Architecture Patterns — Bohdan Orlov
Model-View-ViewModel with swift — SwiftyJimmy
Swift Tutorial: An Introduction to the MVVM Design Pattern — DINO BARTOŠAK
MVVM — Writing a Testable Presentation Layer with MVVM — Brent Edwards
Bindings, Generics, Swift and MVVM — Srdan Rasic

In my previous article, How not to get desperate with MVVM implementation, we learned the Model-View-ViewModel (MVVM) architecture and saw how to create a simple gallery app by using it. With the help of the MVVM, we separate the business logic and presentational logic from the view logic. The separation of concerns (SoC) makes writing unit tests easier than ever. Even though the idea of the MVVM is simple, writing unit tests for its various use cases is still worth mentioning. So in this article, we will step further and learn how to brew unit tests for MVVM.

In short, I will cover two techniques:

• How to design a mock to simulate different network states.
• How to use stubs to test user interaction.

Let’s start with the gallery app we crafted in my previous guide, mentioned above.

A simple gallery app

To recall, the simple gallery app has the following functionalities:

1. The app fetches popular photos from 500px API and lists photos in a UITableView.
2. Each cell in the table view shows a title, a description and the created date of a photo.

The first screen in the app is called PhotoListViewController, the data flow is depicted in this figure:

The APIService takes the responsibility of the network layer, such as setting up the URL, sending the request, etc. The PhotoListViewModel asks the APIService for photo objects and provides the presentational interfaces for the PhotoListViewController. The PhotoListViewController is a simple View, rendering the visible element according to the data presented by the PhotoListViewModel.

Here are some use cases that we are going to test in this article:

1. The PhotoListViewModel should fetch data from the APIService.
2. The PhotoListViewModel should display an error message if the request failed.

The PhotoListViewModel should allow the segue to the detail page if a user presses on a “for sale” photo.

MVVM and Dependency Injection

Here’s part of the implementation of the PhotoListViewModel:

We use a technique named dependency injection (DI) to design our PhotoListViewModel. The property, apiService, is a dependency of the PhotoListViewModal. The apiService takes care of all networking things and provide a handful interface for the PhotoListViewModel to get returned data. The most important thing is, it can be assigned by all objects conforming the APIServiceProtocol.

In the production environment we assign an APIService object, which connects to a real server, to the PhotoListViewModel. On the other hand, in the test environment, we inject a mock APIService object instead. The mock APIService (MockAPIService) object doesn’t connect to the real server, it’s an object designed only for the test. Both APIService and MockAPIService conform the protocol, APIServiceProtocol, so that we are able to inject different dependency in different situation.

If you’re not familiar with the idea of dependency injection, feel free to check my article: The complete guide to Network Unit Testing in Swift :)

The following figure shows the relationship between the PhotoListViewModel and its dependency:

The idea of injection will be more clear in the setUp() and the tearDown() code snippets below. We initialize the PhotoListViewModel with an APIService object, but we use a MockAPIService object instead in the test environment:

In the following section, we are going to see how to design the MockAPIService to simulate a different situations for all test cases.

Behavior test

Our first use case is:

1. The PhotoListViewModel should fetch data from the APIService.

That is, we want to check if the PhotoListViewModel really requests data from the APIService.

Here’s the implementation of the mock:

In order to be injected into the PhotoListViewModel, the mock should conform the APIServiceProtocol protocol. So we create the required method, fetchPopularPhoto(complete:) to conform the protocol. Now we want to make sure if the PhotoListViewModel called the fetchPopularPhoto(complete:) method to fetch the data, so we create a property, isFetchPopularPhotoCalled, in the MockAPIService. Remember that the apiService property is a MockAPIServiceobject in a test environment? The isFetchPopularPhotoCalled will be set to true if the mock function fetchPopularPhoto(complete:) is called by the PhotoListViewModel.

Here’s is the code for our first test:

This is a simple test case. The sut (SUT, System Under Test) is a PhotoListViewModel instance. The code snippet shows that when the PhotoListViewModel fetches data, we check if it called the fetchPopularPhoto(complete:) method. By using this technique, we are able to check if PhotoListViewModel calls specified methods for the dependency injection. In other words, we successfully test the behavior of our ViewModel.

Success or Failure?

In addition to the behavior test, we also want to see if the PhotoListViewModel correctly handles networking states. By using the DI technique, we are able to simulate the success and failure networking states by changing the response of the MockAPIService. In this section, we are going to see how to change the response state of the MockAPIService. Let’s check the second use case as in the example below:

1. The PhotoListViewModel should display an error message if the request failed.

According to the use case, we write the following test code:

The error object represents the given condition of this test case: the request will fail due to a permission issue. After setting up the given condition, we call sut.initFetch() to start fetching data. Then here’s a trick: we ask the mock to fail the request by calling the fetchFail(error:) function. Finally, we assert the alert message of the PhotoListViewModel to see if it handles the error correctly.

So, how to design the MockAPIService? Let’s go back to the implementation of the PhotoListViewModel.initFetch()：

The initFetch() triggers the apiService.fetchPopularPhoto(complete:), assigns a callback closure, and waits for the apiService to call the callback closure. The callback closure is the key!. If we want to simulate a failed request, we can trigger that closure with an error in the MockAPIService. This is the implementation of the MockAPIService:

In the code snippet, when the fetchPopularPhoto(complete:) is called, the callback closure is saved to the completeClosure for the later use. On the other hand, for the PhotoListViewModel, the function call is finished but the escaping closure is still pending. The closure won’t be triggered until the fetchSuccess() or the fetchFail(error:) is called. Finally, when we call the fetchSuccess() or the fetchFail(error:), the PhotoListViewModel receives the response data and continue to finish its jobs.

Now the MockAPIService is able to simulate any kind of asynchronous request. For example, we are able to assert the loading state of the ViewModel: isLoading should be true before fetchSuccess() is called. This is a powerful technique because it mimics an async call, and it could be done immediately.

Let’s get some stubs ready

The ViewModel receives the user interaction and changes the presentation with respect to the interaction. In MVVM, the user interactions are abstracted into a set of methods such as userPressed(), userSwipe(), etc. Therefore, testing the user interactions is straightforward: we call a certain method and assert the corresponding property of the ViewModel. Let’s check the third use case we are going to test:

1. The PhotoListViewModel should allow the segue to the detail page if a user presses on a “for sale” photo.

As we did before, we first write the test code:

This test case describes a user who presses on the first cell, and we are going to see if the segue is allowed. The problem is, we haven’t fetched any photo yet and the sut is currently in the empty state. So if we trigger the sut.userPressed(at:) at this stage, the out of bounds exception will be raised. We need to grab some data first!

The data we need is Photo objects. We want the MockAPIService to return the photo objects to the PhotoListViewModel, just like what it’s supposed to be in the production environment. After the apiService returns the data to the PhotoListViewModel, we are able to trigger the sut.userPressed(at:) and assert the isAllowSegue. The photo objects we created for the test are called “stubs”. I won’t dive deep into the definition of “stub”, but if you’re interested, go check my article on cracking tests for Core Data.

The implementation of the MockAPIService now becomes:

We create an array, completePhotos, to save the stubs. And those stubs will be returns to the PhotoListViewModel once the PhotoListViewModel calls fetchPopularPhoto(complete:). Then let’s take a look at our test code:

The StubGenerator().stubPhotos() generates couple of photo objects. Then we assign the photo objects to the mockAPIService.completePhotos. When the request finished (mockAPIService.fetchSuccess() is called), the PhotoListViewModel will receive those photo stubs via the callback closure. With the help of those stubs, we are able to assert a certain action such as user presses on a specific IndexPath and so on.

More tests…

We are able to use the knowledge we have learned to write more test cases:

1. The loading animation should start when the network request starts.
2. The loading animation should stop when the request completes.
3. The table view should render correctly.
4. It should display error message when user press on the photo that is not for sale.

All of those are included in my GitHub:

koromiko/Tutorial

Tutorial - Code for https://koromiko1104.wordpress.com

github.com

Recap

In this article we used a MockAPIService to check:

• If the SUT correctly interacts with the APIService.
• If the SUT handles the error state correctly.
• If the SUT handles the user interaction correctly.

Conclusion

There are still a lot of things to do. As I mentioned in my previous article, the MVVM has its limitations and cons, such as the anti-pattern of the single-responsibility and the lack of the builder and the router. When it comes to writing tests, I didn’t cover the unit test for the binding and routing. Besides, the state of the SUT could be handled better (There’s a good article talking about the state: iOS Architecture: A State Container based approach).

However, the MVVM does remove the obstacle in writing tests: it’s easier to test the presentational logic. And writing tests for user interaction becomes straightforward as well. The most important thing is that the MVVM is simple and intuitive. It’s a good start point for you to understand the idea of dependency injection and module composition. In the following articles, I’ll continuously refactor our simple gallery app to make it more consolidated and beautiful. So, stay tuned!

Reference

Testing View Controller — Part 1 — Clean Swift
Unit Testing iOS in Swift — Part 2: A Testable Architecture
How to unit test ViewModel in Swift — SwiftyJimmy

iOS/macOS development is really interesting.
You can get domain knowledge in so many fields! You might learn the graphic techniques such as Bezier or 3D transform. And you need to understand how to work with database or design an efficient schema. Moreover, you should be able to manage memory in an embedded-system way (especially for those who were in the great MRC era). All of those make iOS/macOS development so diverse and also challenging.

In this article, we’ll learn yet another thing you probably need to know: Continuous Delivery (CD). Continuous Delivery is a software approach that helps you release products reliably, at any time. The CD usually comes with the term Continuous Integration (CI). CI is also a software engineering technique. It means that the system continuously merges developers’ works to a mainline all the time. Both CI and CD are not only useful to a big team but also useful to a one-man team. And if you are a sole developer in a one-man team, CD probably means more to you since delivery is unavoidable to every application developer. So this article will focus on how to build a CD system for your application. Fortunately, all of those techniques can be adopted in the construction of a CI system as well.

Imagine that we are developing an iOS app named Brewer, then our workflow will look pretty simple:

First, we develop. Then QA team helps us manually test the app. After the QA approves the test build, we release (submit to the AppStore for review) our app. In different stages, we have different environments. During development, we build the app in a staging environment for testing every day/night. When QA team is testing, we prepare an app built with production environment. This could be a weekly build specially for QA team. Finally, we submit the app using Production environment. Such final builds could have no predefined schedule at all.

Let’s take a deeper look at the delivery part. You might find that we have a lot of duplicated work on building test apps. Here’s what the CD system can help you with. Specifically, our CD system needs to:

1. Build the app in different environments (staging/production).
2. Sign the code according to the environment we choose.
3. Export the app and send it to a distribution platform (such as Crashlytics and TestFlight).
4. Build the app according to a specific schedule.

Outline

Here is what we’re gonna do in this article:

• Setup your project: How to setup your project to support the switch between different environments.
• Sign the code manually: How to handle the certificate and provisioning profile manually.
• Standalone environment: How to Use Bundler to isolate the system environment.
• Build with fastlane 🚀: How to build and export the app using fastlane.
• Jenkins will be your server for tonight: How Jenkins helps you scheduling your tasks.

Before we start, you probably want to check out:

• What’s fastlane
• What’s Jenkins
• What’s Code signing

If you’re a busy guy/girl, no worries, I made the Brewer app a public repository with sample script for you!

koromiko/Brewer

Brewer - We brew beer every night!

github.com

So, let’s start!

Setup your project

We usually connect to a development server or a staging server on developer test stage. We also need to connect to a production server when releasing the app to a QA team or AppStore. Switching the server by editing the code might be not a good idea. Here we use the build configuration and the compiler flag in Xcode. We won’t dive into detail about the configuration. If you’re interested in the setup, check this great article by Yuri Chukhlib:

Manage different environments in your Swift project with ease

medium.com

In our Brewer project, we have three build configurations:

• Staging
• Production
• Release

Each of which maps to a specific Bundle identifier:

We set up the flag to help our code know which server environment are we using.

So we can do something like this:

Now we are able to change the staging/production environment by changing the build configuration, without modifying any code! 🎉

Sign the code manually

This is a well-known red button for every iOS/macOS developer. We start every project by unchecking this box. But why it’s so notorious? You might know that it download the certificate and the provisioning profile, embed those to your project and system. If any file missed, it makes a new one for you. For a one-man team, nothing wrong here. But if you’re in a big team, you might accidentally refresh the original certificate, and then the building system stops working due to the invalid certificate. To us, it’s a black box hiding too much information.

So in our Brewer project, we want to do this by hand. We have three app IDs in our configuration:

• works.sth.brewer.staging
• works.sth.brewer.production
• works.sth.brewer

We’ll focus on first two configurations in this article. Now we need to prepare:

• Certificate: An Ad Hoc/App Store distribution certificate, in .p12 format.
• Provisioning Profiles: Ad Hoc distribution provisioning profiles for two app identifiers, works.sth.brewer.stagingand works.sth.brewer.production.

Note that we need the p12 format of the certificate file, since we want it to be portable to different machines, and only .p12 format containing the private key to the certificate. Check this to see how to convert .cer file (DEM format) to .p12 (P12 format) file.

Now we have our code signing files in a folder:

Those files are used by the CD system, so please put the folder on the CD machine. Please don’t put those files with your project, don’t commit them to your project repository. It’s okay to host the code signing files in a different private repository. You might want to check the security discussion in match — fastlane docs.

Build with fastlane 🚀

fastlane is a tool that automates the development and release workflow. For example, it can build the app, run the unit test, and upload the binary to Crashlytics, in one script. You don’t need to do those things step by step manually.

In this project, we are going to use fastlane to accomplish two tasks:

• Build and release the app running in a staging environment.
• Build and release the app running in a production environment.

The difference between those two methods is merely the configuration. The shared tasks are:

• Sign the code with the certificate and the provisioning profile
• Build and export the app
• Upload the app to Crashlytics (or other distribution platform)

Knowing our tasks, we can start to write the fastlane script now. We will use the fastlane for Swift to write our script in this project. The fastlane for Swift is still in beta, so everything works well except:

• It doesn’t support plugins
• It doesn’t catch exceptions

But writing the script in Swift makes it more readable and maintainable for the developers. And you are able to convert the Swift script to Ruby script with ease. So let’s try it!

We first start our project (still remember the Bundler?):

bundler exec fastlane init swift

Then, you are able to find a script in fastlane/Fastfile.swift. In the script, there’s a fastfile class. It’s our main program. Every method named with postfix, “Lane”, in this class is a lane. We can add predefined actions to a lane, and execute the lane with a command:

bundle exec fastlane <lane name>.

Let’s fill in some code:

We create two lanes: developerRelease and qaRelease for our tasks. Both tasks do the same thing: build a package with the specific configuration and upload the exported ipa to Crashlytics.

There’s a method package in both lane. The interface of package() looks like:

The parameter is an object conforming the protocol Configuration. The definition of the Configuration is:

Then we create two structs conforming the protocol:

Using the protocol, we are able to make sure every configuration comes with required settings. And we don’t need to write the package detail every time when we have a new configuration.

So how does the package(config:) looks like? First, it needs to import the certificate from the file system. Remember our code signing folder? We use importCertificate action to achieve our goal.

keychainName is the name of your Keychain, the default one is called “login”. The keychainPassword is the password to your Keychain, fastlane uses it to unlock your Keychain. Since we commit the Fastfile.swift to the repository to make sure the delivery code is consistent in every machine, it’s a bad idea to write the passwords as string literals in the Fastfile.swift. Therefore, we use environment variable to replace the string literal. In the system, we save environment variable by:

export KEYCHAIN_NAME=”KEYCHAIN_NAME”;
export KEYCHAIN_PASSWORD=”YOUR_PASSWORD”;

In the Fastfile, we use environmentVariable(get:) to get the value of the environment variable. By using the environment variable, we can avoid showing the password in the code and greatly improve the security.

Back to the importCertificate(), the certificatePath is the path of your .p12 certificate file. We create a enum named “ProjectSetting” to keep the shared project setting. Here we also use the environment variable to pass the password.

After importing the certificate, we are going to set up the provisioning profile. We use updateProjectProvisioning:

This action gets the provisioning profile, imports it and modifies your project setting in the specified configuration. The profile parameter is the path to the provisioning profile. The target filter uses regular expression notation to find the target that we want to modify. Note that the updateProjectProvisioning does modify your project file, so please be careful if you want to run it on your local machine. It doesn’t matter to CD task since the CD system won’t commit any change to the repository.

Okay, we finished the code signing part! The following part would be quite straightforward, so bear with me!

Let’s build an app now:

buildApp helps you build and export your project. It calls xcodebuild under the hood. Every parameter is intuitive except the exportOptions. Let take a look at it：

Unlike other parameters, it’s a dictionary. “signingStyle” is how you want to sign your code, we put “manual” here. “provisioningProfiles” is also a dictionary. It’s the mapping between the app id and the corresponding provisioning profile. Finally we finished the fastlane setup! Now you can do this:

bundle exec fastlane qaRelease

or this:

bundle exec fastlane developerRelease

to release test build with proper configurations!

Jenkins’ll be your server for tonight

Jenkins is an automation server that helps you to perform the CI/CD tasks. It runs a web GUI interface and is pretty easy to customize, so it’s a great choice for an agile team. The rule of the Jenkins in our project can be depicted in the following graph:

The Jenkins fetches the latest code of the project and runs tasks periodically for you. In the execute shell section, we can see that Jenkins actually performs the task that we just did in the previous sections. But now we don’t need to do them ourselves, Jenkins does this for you seamlessly!

Start from the nightly build job, let’s start to create a Jenkins task. First, we create a “freestyle project”, and enter the “Configure” page of it. The first thing we need to configure is the Source Code Management(SCM) section:

Repository URL is the source code url of the project. If your repository is a private one, you need to add Credentials to get the access to the repository. You can set target branch in the Branches to build, usually it’s your default branch.

Then, below we can see Builder Trigger section. In this section we can decide what’s going to be the trigger of the build job. According to our workflow, we want it to start every weeknight.

So we check the Poll SCM, it means that the Jenkins will poll the designated repository periodically. In the schedule text area:

H 0 * * 0–4

What does it mean? Let’s check the official instruction:

It consists of five fields:

• minute
• hour
• day
• month
• weekday

The field could be a number. We can also use “*” to represent “all” numbers. And we use “H” to represent a hash, auto-selected “one” number.

So our schedule:

H 0 * * 0–4

means: the job runs at certain minute from 0am to 1am every night, from Sunday to Thursday.

Last but not least, let’s check the Build section below. Here’s the task we want Jenkins to execute:

export LC_ALL=en_US.UTF-8;
export LANG=en_US.UTF-8;export CODESIGNING_PATH=”/path/to/cert”;
export CERTIFICATE_PASSWORD=”xxx”;
export KEYCHAIN_NAME=”XXXXXXXX”;
export KEYCHAIN_PASSWORD=”xxxxxxxxxxxxxx”bundle install — path vendor/bundler
bundle exec fastlane developerRelease

First 6 lines are setting the environment variables that we described before. And the 7th line installs the dependency, including the fastlane. Then the last line executes a lane named “developerRelease”. To sum up, this task builds and uploads a developerRelease every weekday night. This is our first nightly build! 🚀

You can check the building status by clicking the build number in the side menu of a Jenkins project page:

Summary

Together with you we have learned how to create a CD system with fastlane and Jenkins. We understood how to manually manage the code signing. And we created a lane running the task for us automatically. We also explored how to switch the configuration without changing the code. Finally, we built a CD system that builds an app every night.

Although many iOS/macOS applications are created in one-man teams, automating the delivery process is still a high-leverage improvement. By automating the process, we can reduce the risk of delivering with a wrong configuration, avoid being stuck by expired code signing and reduce the waiting time of the build upload.

The workflow introduced in this article might not be exactly the same with yours, but it’s really important to know that every team has its own workflow and pace. So you must create your own CD system to meet the need of your team. By using the techniques as building blocks, you must be able to build a new customized and better-fit CD system yourself!

推出你的影響力：每個人都可以影響別人、改善決策，做人生的選擇設計師

這本書在行為經濟學中，佔有一席之地，主要的原因一之，大概是因為它是一本非常容易閱讀的書籍，作者的寫作風格非常輕鬆休閒，也不過份主觀，加上例子都是實際案例，讀起來特別有趣。

Nudge是輕推的意思，在這本書中主要指稱在人們做決策時，很容易受到一些外在因素的影響，而這些外在因素有時候很簡單，可能只是提供更簡化的選項、提供預設選項等等，光是這些簡單的變化，就足以影響人類做出不一樣的選擇。相較於像法律、制度、規範等等如果不跟著照作，就可能無法在這社會中生存，輕推的中心思想是，希望提供人們在選擇上最大的自由，但同時也引導人們選擇專家們認為對他們比較有利的選項，在這本書中，這樣的做法被稱為自由家長制(libertarian paternalism)，相對的強制人們選擇的制度，被稱之為家長制(paternalistic)。

整本書大概可以分成兩個部份，第一個部份主要介紹社會大眾是多麼容易被影響，這邊的理論跟快思慢想一樣，人腦在做決策時，通常情感因素占了很大一部份，也就是快思慢想中的系統一總是能夠主導思考。而也是因為如此，在政府推行政策的時候，多少可以利用這個特點，讓政策能夠在不損害自由的情況下被順利推行。第二部份就開始利用許多真實案例，講述選擇設計師如何發揮輕推的力量，讓管理者能夠事半功倍。如果你是崇尚自由意志的人，可能會覺得這樣的作法有點爭議，但回歸到現實面上，大多數的社會大眾，是無法完全理性思考的，如果有專家的協助，對於整個社會的助益會相當大。在總結的部份，作者也讓我們了解到，不是所有議題都能夠透過自由家長制推行，也不是自由家長制就完全沒問題，但是從過往的經驗來看，絕對是一個有效而且效果顯著的方法。

這本書的概念非常地中性並且可行，自由家長制也在完全自由意志跟完全管制中，取得了一個不錯的平衡，就現實來說，自由家長制在效率上或許不如強制執行那樣有效，但保留了最大的自由給持有不同意見的群體，個人覺得不論政府或是公司，在管理上都很需要再多花心力，在能夠輕推的地方，施加一點力道，降低整個群體乃至社會的整體成本。

這是一本中文版總共有六千多頁的鉅作，由生物地理學家 Jared Diamond 撰寫而成。這本書光是閱讀就花了我三個月的時間（當然中間有交錯看了幾本其它的書換換心情XD），更不用說對於作者來說，要完成這本書需要多驚人的時間。原本對於這本書沒有太大的興趣，以為它就是另外一本後見之明的歷史著作，但是在看完 Harari 的「人類大歷史」之後，覺得雖然歷史很難正確地分析，但是這類旁徵博引、用大量的史料跟研究來支撐論點的著作卻是意外的非常有趣。尤其是「人類大歷史」雖然有趣，但是看完之後還是很想再繼續了解像是東西方差異、近代歷史的癥結點等等，所以又去找了這本書來看。

這本書一開始就先從人類的農業開始講起。人類的農業起源地分布在世界各地，其中以兩河流域的肥沃月彎為最早的農業起源、接著發生在古代中國、新幾內亞然後慢慢遍布到世界各地。但是你有沒有想過，世界各地的農業都是獨立發展，還是從肥沃月彎開始慢慢傳到世界各地？從農業再衍伸到近代，為甚麼有些國家在西元 1600 後成為帝國，而有些國家卻一直到近 20 年才開始脫離採集狩獵的原始生活？世界各地的交流絕對不是近代才開始的，但是即使在一萬年前人類就有跨越大陸傳播知識的先例，美洲大陸的傳播就是比歐亞大陸的傳播更為緩慢，這又是為甚麼？

這本書的每一個章節都讓人感到振聾發聵，之前讀歷史的時候，只覺得肥沃月彎跟中國都是因為土地肥沃、氣候條件佳，才有辦法發展出龐大的農業社會，但是顯然這兩項條件還不夠，土地氣候佳的地方在當時那個年代並不是只有肥沃月彎或中國才有，只不過這些早期就發展出農業的社會有個非常重要的先決條件，就是在當地垂手可得的作物，都是適合馴化的。人類不是在幾千年前的某一天就突然學會的農業，也不是一覺醒來就知道那些植物是可以馴化、種植的，如果你身邊的植物都桀傲不馴，當然你的社會也就難以發展出農業。作者光是在馴化植物的章節，就花了一千多頁的篇幅在講解農業的起源、各地發展差異的遠因，還有時間拉到西元後，導致國家之間發展差異的近因，可以說非常的鉅細靡遺，但是又不會像學術著作那樣深奧難懂。接續農業發展的分析，作者在後面的章節繼續把時間推到文明史，找出各地發展差異的遠近因，再慢慢推到西元 1600 開始的世界劇變，這幾個章結雖然橫跨了各大洲、經過了幾千年，但是作者卻能夠把這些發展的因果緊密地扣在一起，讓人非常佩服作者組織這樣龐大史料跟觀點的能力。

蠻多人會把「人類大歷史」跟「槍砲、病菌與鋼鐵」兩本書放在一起談，因為這兩本都是大史觀的著作，用非常宏觀的角度來看過往人類的歷史。不過很明顯「人類大歷史」的許多觀點都跟「槍砲、病菌與鋼鐵」是有重疊的，而在這些重覆的地方，「槍砲、病菌與鋼鐵」又再多了數倍以上的資料在建構這些觀點。這也讓「槍砲、病菌與鋼鐵」這本書比「人類大歷史」要難讀不少，但能夠得到的觀點還有分析也是數倍之多。更讓人佩服的是，作者在這麼大量的資料上組織出來的內容卻還是相當有條理並且易懂。這兩本書我覺得都是大史觀的經點鉅作，但是如果不害怕大量文字跟資料的話，我會非常推薦「槍砲、病菌與鋼鐵」，它帶來的震憾真的不是其它歷史著作能夠比擬的。

String type is a fundamental type of all programming languages. It’s also the very first language that you will learn when start programming. The String type is easy and straightforward. However, on the other hand, it is very complicated under the hood. The String type needs to handle the glyphs of various languages, the reading order of languages, and many other locale-specific behaviors. Moreover, the storage and the display of a String in the modern computer system is also a big issue. All of those are elegantly wrapped into an easy and intuitive String type.

When it comes to Swift, in Swift, the String type could be very intuitive, like concatenate Strings by using the “+” operator. It could also be very complicated, such as access a specific character in a string. Why String type is so controversial in Swift? Why can’t we use the subscript pattern to access a character in the string? How does Swift fully support the Unicode and why does it matter? In this article, we will dive deep into the fundamental of the String type, from the String Encoding to the Swift String API. After reading this article, you will learn:

• What’s String Encoding, Unicode, UTF-8, etc…
• How does Swift achieve the Unicode-compliance
• Swift String API: index, comparison, substring, etc..
• The relation between NSString and Swift String

The Swift version of the code snippets is 4.2. But except the Swift String API, the fundamental concepts are invariable within different versions.

Let’s start from the world outside Swift, back to the old good days 💾

Character encoding

As an engineer, you must be very familiar with the ASCII code. Since the computer world is composed by 0 and 1, we must have an encoding system to represent the human characters by numbers. ASCII is a good example. The character “A” is encoded by a decimal number “65”, “B” is encoded by a decimal number “66”, and so on. The ASCII can represent 256 characters, including the whole 26 alphabetic characters. In that 640k-is-enough era, it looked enough for encoding all English words. However, there are way more characters in languages other than English. The most common Korean characters is around 2,000. Not the mention the Chinese, which has over 50,000 characters. In order to make all languages in the world could be represented in the computer, we need a better encoding system. So the Unicode is here to rescue!

Before we jump into the Unicode system, let’s take a deeper look at what’s the Character Encoding. Character Encoding is a system used to represent characters by numbers. The purpose of doing encoding is because that we want to save, display, or distribute the language in the computer, and the computer can only deal with numbers. Intuitively, we can have a huge paper sheet, transcribing all characters and mark all of them with serial numbers. This huge paper sheet is called the “Code Space”. And the number assigned to each character is called the “Code Point”. Given this huge paper sheet, we can encode a paragraph of any language into a series of numbers, by looking up the Code Points for all characters in the paragraph. We can also load a series of numbers from a computer, and look up corresponding characters to decode them back to a paragraph. Briefly speaking, this imaginative huge paper sheet is the Unicode.

A single Unicode code point could be as small as 1, 2, 3…, it could also be as large as 0x1F3C2 in Hex. The storage unit of a computer is by bytes (0~255). So you might wondering, if we need to save the code point into the computer storage, how many bytes do we need for a single code point? Let’s take a look at an example:

"🏂 costs ¥"

This is a sentence with different special characters. The whole sentence can be represented by Unicode code points, as the following table:

The first character, 🏂, is an snowboarding emoji. In Unicode system, the code point of it is U+1F3C2, which is a 17-digit binary number 11111001111000010.

Now, we want to store those characters into the computer. Though the code points are numbers, in order to save those into the computer system, we need find a way to convert those numbers into bytes. Remember that the largest code point has 17 digits, so a 32-bit container is a good choice. One 32-bit container can store a English character such as “c” (code point: 99), it can also store a emoji “🏂” (code point: 127938). By using 32-bit containers, we can store all Unicode code points without any conversion. On one hand, it’s convenient because we don’t need to convert any code point, on the other hand, it wastes a lot of spaces. Most of common characters’ code points are only 8-bit, use 32-bit containers to save 8-bit data will leave 24 bits unused.

Another method is to use one 16-bit container to save a code point which is smaller than 16-bit, and use two 16-bit containers to save the one larger than 16-bit. The following graph depicts the relation between the code point and the size of different storage containers:

Practically, we have to store the data bytes by bytes. In this graph, the “abstract” is the Unicode code point. The “storage” section is how we break down the code point into bytes. The way we encode the code point is called Character Encoding Form, and the container unit we are using is called Code Unit. A 17-bit code point can be encoded as one 32-bit code unit, or 4 8-bit code units. And as you may guess, the 32-bit character encoding form is UTF-32, the 16-bit one is UTF-16, and the last one is UTF-8. We won’t elaborate the detail of those character encoding forms, but the implementation of those are very interesting. You can check out more details, such as size of code spaces and how supplementary planes works in the wiki page.

Back to the graph above, now we are focusing on the UTF-16 and UTF-8. You may notice that we use two 16-bit code units and four 8-bit code units to represent the 17-bit code point. How about encoding the smaller code point? We use less code units! The table below shows the facts that, for UTF-16 and UTF-8, the length of code units for encoding a code point are variable. This fact is very important, we’ll dig into this in the following section!

Now let’s go back to the modern era, to see how Swift works with the String type.

Unicode and Swift

Swift String type provides several Unicode-compliance API for working with various languages. In this section, we will introduce some handful Swift String APIs for dealing with Unicode or internationalization.

String Literal

In Swift, we can initialize a String by giving the code point directly. For example:

var stringLiteral = “\u{1F30A}” // "🌊"

or,

var stringLiteral2 = “\u{8702}\u{871c}\u{6ab8}\u{6aac}” // "蜂蜜檸檬"

UnicodeScalars

You can also convert a string to code points:

var scalars = “🌊”.unicodeScalars // 127754, or 0x1F30A

The unicodeScalars is a Collection of Unicode.Scalar, means that you can do loop over it, or use the map, filter on it. A Unicode.Scalar represents a code point in Unicode, excluding the surrogate code points, which are functional code points used by UFT-16. Swift also provides functions for getting the code units of different character encoding form. Based on what we learn in the previous section, we won’t be surprised to see the counts of code units vary among different encoding forms.

let snowboardCostYen = "🏂 costs ￥"
snowboardCostYen.unicodeScalars     // count = 9
snowboardCostYen.utf16              // count = 10 
snowboardCostYen.utf8               // count = 14

Grapheme Cluster

Generally, in Unicode, a character is represented by a single code point. But you can use more than one code point to represent a more complicated character. For example, the code point of an English character “e” is U+65. If we concatenate the U+65 with a acute code point U+301, we will get the e-acute character “é”:

let eCharacter = "\u{65}"             // "e"
let graphemeCluster = "\u{65}\u{301}" // "é"

This kind of combination is called Grapheme Cluster. A grapheme cluster is made by variable-length code points. A typical example of this is Hangul, a Hangul character could be made by three different Jamos:

let first = "\u{1112}"                      // "ᄒ"
let second = "\u{1161}"                     // "ᅡ"
let third = "\u{11AB}"                      // "ᆫ"
let cluster = "\u{1112}\u{1161}\u{11AB}"    // "한"

Grapheme cluster is not necessarily composed by two code points, you can append more marks to a normal character to make a more complicated character:

let enclose = “A\u{20DD}\u{301}”           // A⃝́

How complicated would it be? Here is a scaring example of Zalgo:

var zalgo = "Z̫̫̳̰̦͙͙̒̇̽̒͗̑̂̋̚ạ͈̳̟̙͉̥̦̙̒̔̃͋̅͛̐l͕̯̟͖̣͊̓̒̂̑̽̊̃͑̃̓̽ḡ̟̲͚̞͆͊̋̏̽̏̉ͅô̤͈̩̖̞̙̲͚͍͓̘͉͂́̆"

If you check the code points of this string by printing zalgo.unicodeScalars, you may find that it’s made by five simple English characters, “Zalgo”, followed by a ton of combining marks. Currently, Swift supports the Extended Grapheme Clusters, you can check UNICODE TEXT SEGMENTATION for more detail.

Here’s another interesting fact of Swift string, let’s print the count for each of the example above:

let cluster = "\u{1112}\u{1161}\u{11AB}"    // "한"
let enclose = “A\u{20DD}\u{301}”           // A⃝́

print(cluster.count)     // 1
print(enclose.count)     // 1

Though the code points are more than one, the counts of those strings are still 1, which are consistent to the number of grapheme clusters in the string. Moreover, if you use a for loop to print the element of the string cluster, only one character “한” will be printed. All in all, in Swift, you can expect that the manipulation of the String type is as what you will see by human eyes.

Everything has two sides. To calculate the number of all grapheme clusters, we need to scan the whole string to determine which of those are clusters, which are not. Now you won’t be shocked if I say the time complexity of the .count API is O(n) in Swift, and there’s no random access to a Swift string!

Let’s keep this fact in mind, we’ll see more Swift String API related to this fact in the following section!

String API in Swift

String Index

Now we know that Swift String cannot be random access, then how do we access a specific character in a string? We can use the String.Index:

let snowboardCostsYen = "🏂 costs ¥"
print(snowboardCostsYen[8])      // Error!

let idx = snowboardCostsYen.index(snowboardCostsYen.startIndex, offsetBy: 8)
print(snowboardCostsYen[idx])    // "￥"

Using the Int subscript to a string infers random access, but using the String.Index subscript doesn’t. Even though the usage here looks complicated, the semantic meaning of this API is clear: be careful, the time complexity of getting the index is not O(1)!

It’s worth mentioning of some bight sides of the String API. Swift String provides many handful APIs for you. In .index(i:, offsetBy:) API, the offsetBy could be negative:

let head = snowboardCostsYen.index(snowboardCostsYen.startIndex, offsetBy: 2)
let tail = snowboardCostsYen.index(snowboardCostsYen.endIndex, offsetBy: -3)
let costSubstring = snowboardCostsYen[head...tail] // costs

The tail in above’s example indicates the third position from the end of string snowboardCostsYen, which is equivalent to snowboardCostsYen.index(snowboardCostsYen.startIndex, offsetBy: 6).

If you want to look up the index of a specific character, you can use:

let findIdxFirst = snowboardCostsYen.firstIndex(of: "￥") 
let findIdxLast = snowboardCostsYen.lastIndex(of: "￥") 

Those make the string index manipulation becomes very easy.

More detail about the String Index, especially for the design principle, check String Index Overhaul.

String Comparison

Back to character, it’s possible that two characters share the same glyph, while are composed by different code points. The e-acute “é” is a good example:

let acute1 = "\u{E9}"          // "é"
let acute2 = "\u{65}\u{301}"   // "é"
print(acute1 == acute2)        // true

In this case, acute1 and acute2 look like the same, but the code points are different. If we compare those two string, Swift returns true. Again, Swift makes the API consistent with the natural result.

A special case is the English “A” and the Russian “А”:

*let* latinCapitalLetterA = “\u{41}”                    // "A"
*let* cyrillicCapitalLetterA = “\u{0410}”               // "А"   
print(latinCapitalLetterA == cyrillicCapitalLetterA)    // false 

Different from the e-acute case, these two characters are literally different, so it’s reasonable that Swift returns false.

Substring

From the example in the previous section:

let head = snowboardCostsYen.index(snowboardCostsYen.startIndex, offsetBy: 2)
let tail = snowboardCostsYen.index(snowboardCostsYen.endIndex, offsetBy: -3)
let costSubstring = snowboardCostsYen[head...tail] // costs

If you check the type of the costSubstring, you may find that it’s a Substring instead of a String. What’s the differences between String and Substring? In order to improve the performance of the String, when getting the substring from a string, Swift actually doesn’t allocate new memory space for the substring. Instead, it creates a range indicator, pointing out the range of the substring in the original string. The following graph depicts the relation:

The blue rectangle in the memory space occupied by the original string. When we create a substring, a new range indicator will be created, as the black hollow rectangle upon the blue one. No new memory space is needed. By doing this, substring manipulation in Swift is very fast and efficient. Besides, both String and Substring conform to the StringProtocol, so the usage of Substring is almost the same with the String. 👍

Wait, you said the substring use the same memory space with the host string? So now two references are pointing to the same memory space? You bet! If you keep the reference to the Substring in somewhere else, the whole memory space of the original string will still be retained. As long as the substring reference is alive, space will be retained even when you remove the reference of the original string! Usually, Substring type is used as an intermediate. Means that it’s better to use the substring in a local scope, such as in a function or a closure, and release it once we don’t need it.

In swift-evolution, we can find more design mindset of the Substring.

String Performance

Similar to the Substring, the memory techniques are used for the copy of strings as well. Given a string, strA, we create a new string variable, strB, and assign the strA to the strB:

let strA = "string A"
var strB = strA

print(Unmanaged.passUnretained(strA as AnyObject).toOpaque())  // 0xbd0a6cb38041f74b
print(Unmanaged.passUnretained(strB as AnyObject).toOpaque())  // 0xbd0a6cb38041f74b

You will find that, even though the String is value type, they are sharing the same memory space! Now let’s make some tweaks on the strB:

strB.append("c")
print(Unmanaged.passUnretained(strB as AnyObject).toOpaque())  //0xbdc86da32414008a"

The memory address of the strB changed! Here Swift plays a trick called Copy-on-write. That is, if you’re just assigning the string to a new variable without any modification, they will all share the same memory space. It makes the copy of string very fast and space-efficient. On the other hand, the new memory space is allocated only when the string is going to be modified. In most cases, strings are copied without modification, there’s no point to allocate memory spaces if we are just reading them. This copy-on-write behavior works only behind the scenes, the interface behavior of a string remains the same as a value type.

NSString v.s. String

If you were born before 2014, or technically, you started writing iOS/macOS programs before 2014, you might be familiar with many NS-prefixed classes. Here we are going to discuss one of the NS-prefixed classes: NSString.

In Swift, a String could be just a Swift String, or it could be a NSString instance. Swift bridges the String and NSString, so you can simply use a type cast, “as”, to convert between those two types. Based on this, here’s a very interesting case:

let nStr: NSString = "🏂 costs ￥"
let sStr: String = nStr as String // Still NSString
let aNewStr = nStr + ""           // aNewStr is a String now

In the beginning, we define a NSString, cast it to a String. Now the compiler treats this sStr as a String, though it’s still a NSString instance. By adding a “” by using “+” operator, aNewStr now is a String instance instead of a NSString instance. This observation is introduced by Ole Begemann in objc.io. This does matter because generally, the performance of a String instance is slightly better than the NSString instance.

Many of NSString methods do not be implemented in Swift String, but if you import the Foundation framework, you will have all the NSString methods bridged to the String type. The .components(separatedBy:) is an example:

import Foundation
let sStr = "🏂 costs ￥"
sStr.components(separatedBy: " ")

About the encoding logic, NSString is different from the String. The encoding logic of the NSString is on the UTF-16 point of view, while the String is Unicode-based. What does it mean? If we check the length of a String and a NSString:

let nStr: NSString = "🏂 costs ￥"
print(nStr.length) // 10

let sStr: String = nStr as String
print(sStr.count)  // 9

The length of the sStr is 9, which is the same as the Unicode characters. But the length of the nStr is 10, which is the same with the number of UTF-16 code units. Specifically, the emoji “🏂” is encoded into two code units in UTF-16.

Although the Swift String is Unicode-friendly, practically, a string still needs to be encoded by a character encoding form to be stored in a computer system. In Swift 4, the String uses the UTF-16 (sometimes ASCII for small strings) as the character encoding form. Again, this behavior works seamlessly, you don’t even need to know how does Swift stores those values. All you need to memorize is that Swift String is Unicode-compliant, and that’s it.

Summary

In this article, we went through many aspects of the String type, including the character encoding, the API design, and the performance of it. Understand the character encoding is the key to the rationale of the Swift String API design. Swift is dedicated to making the usage of String intuitive and semantically clear. Besides, we also know that various techniques are adapted for improving the String’s performance. Thought the Swift API is still changing (it changed rapidly 😬), the logic and the mindset behind the API design should be the same. By knowing more implementation details of the Swift String, we are able to catch up the API changes and handle the String correctly in the future. 🍻

References

Strings and Characters — The Swift Programming Language (Swift 4.2)
Strings in Swift 4
Swift String Cheat Sheet

UITableView is definitely one of the most frequently used UI components for every iOS developer. Due to the size limitation of the mobile phone, table view becomes a great way to present information while keeping the clearness of the UI design.

In the good old days, a table view contains typically cells displaying simple information such as a title with an image. And the only interaction is the selection of a cell.

But things change. Today, the table view is getting more and more complicated. Newsfeed, timeline, and wall have been widely adopted, a table view with various cells and asynchronous interactions is a new paradigm. So coding the complex UI is now challenging to developers.

In this article, we will talk how to organize your table view code with the Model-View-ViewModel (MVVM) pattern. MVVM is an architecture pattern that represents the view state using the data model. By making the UI logic a data model, we can use more Swift techniques. Such as protocol and closure to simplified the code in your table view. If you’re not familiar with MVVM, I recommend you to check my previous article for a holistic introduction to the MVVM pattern.

TD;DR

In this article, you will learn how to:

• Newsfeed App
• Hand over the UI jobs
• Create the ViewModel for cells
• Use Protocol to Reduce the Redundancy
• Handle the business logic separately;
• What to read if you want a deeper dive.

Let’s start! 💪

Newsfeed App

Now we are going to craft a newsfeed app. The home page of this app is a personalized “wall.” In the wall, there are two kinds of feeds, the photo feed, and the member feed. We’re going to cover the following use cases:

1. The tableView displays Member’s cell and Photo’s cell correctly.
2. The “+” button shows loading when waiting for the response of the follow-a-member API.
3. Trigger the open-detail event when users press the Photo cell.

Here’s a teaser:

MemberCell
The member cell recommends members that you might want to follow. You can click on the “+” button in the cell. The cell has three states:

PhotoCell
The second type of the cell is a photo cell. In this cell, there are a title, description, and the photo itself. When users click on the cell, the app opens a corresponding photo detail view.

We assume that the response of the API call is decoded into two models: Member and Photo.

If you’re interested in how to make this app from zero to one, you can check my GitHub project GitHub — koromiko/TheGreatWall: Using MVVM to tackle complicated feed view. There are more techniques for consolidating your table view, so remember to check it after reading!

A quick look

Intuitively, we create one FeedListViewController containing a table view, make it as a dataSource and delegate of a table view. This is how the view controller looks like:

var feeds: [Feed] = [Feed]()
var tableView: UITableView

func viewDidLoad() {
    self.service.fetchFeeds { [weak self] feeds in
        self?.feeds = feeds
        self?.tableView.reloadData()
    }
}

func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    return feeds.count
}

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    let feed = feeds[indexPath.row]
    if let memberFeed = feed as? Member, let cell = tableView.dequeueReusableCell(withIdentifier: MemberCell.cellIdentifier(), for: indexPath) as? MemberCell {
        cell.nameLabel.text = memberFeed.name
        cell.profileImageView.image = memberFeed.image
        cell.addBtn.isSelected = memberFeed.isFollwing
        return cell
    } else if let photoFeed = feed as? Photo, let cell = tableView.dequeueReusableCell(withIdentifier: PhotoCell.cellIdentifier(), for: indexPath) as? PhotoCell {
        cell.titleLabel.text = photoFeed.captial
        cell.descriptionLabel.text = photoFeed.description
        cell.coverImageView.image = photoFeed.image
        return cell
    } else {
        fatalError("Unhandled feed \(feed)")
    }
}

Then we need to handle the loading state of the Member cell. Normally, we use an array to save the loading state for all cells:

var cellLoadingStatus: [Bool]

Then update cells by using this:

if cellLoadingStatus[indexPath.row] {
	cell.loadingIndicator.startAnimation()
} else {
	cell.loadingIndicator.stopAnimation()
}

We have one more thing to do. The state update should be handled, like this:

func updateLoadingState(isLoading: Bool, at indexPath: IndexPath) {
	cellLoadingStates[indexPath.row] = isLoading
	tableView.reloadRows(at indexPaths: [indexPath], with animation: .none)
}

It seems to work fine.
Unfortunately, the requirement changed (as it can be in a real life). We are requested to add one more cell type, let’s say, a place cell. What should we do? We’ll add a cell class, add one more else-if statement to the func tableView(tableView:,indexPath:) -> UITableViewCell. If the new cell has different states, we will add one more array to handle the state change and add a function to update the states. Phew! The fragmented code makes changing requirement a challenging task!

The following graph shows the architecture:

In the example above, the dataSource has the following responsibilities:

1. Setups cells’ UI components such as the nameLabel, the imageView, etc.
2. Records cells’ states, e.g., cellLoadingStates.
3. Make an API call and save the model data.

Whenever we add a cell type, we do those tasks in the FeedListViewController, which is not scalable at all. A better way to do this would be separating the responsibilities to improve the scalability. Adding cell type should be more like plugging a USB device to a computer, which won’t change the design of the computer.

There is a lot of work to do, so let’s start with a small step! 🔨

Hand over the UI jobs

Back to the func tableView(tableView:, cellForRowAt indexPath: ) -> UITableViewCell，there’re UI setup such as assigning the nameLabel.text and the imageView.image. It’s not a good idea that dataSource knows the implementation detail of the cell. So our first step is to move the UI setup logic from the dataSource to the cell.

Based on this thought, we add an function to the MemberCell:

// In MemberCell.swift
func setup(name: String, profileImage: UIImage, isFollowing: Bool, isLoading: Bool) {
	self.nameLabel.text = name
	self.profileImageView.image = profileImage
	self.addBtn.isSelected = isFollowing
	if isLoading { 
	    self.loadingIndicator.startAnimation()
	} else {
	    self.loadingIndicator.stopAnimation()
	}
}

With the help of the setup function, we are able to simplified the func tableView(tableView:, indexPath:) -> UITableViewCell, like this:

if let memberFeed = feed as? Member, let cell = tableView.dequeueReusableCell(withIdentifier: MemberCell.cellIdentifier(), for: indexPath) as? MemberCell {
    cell.setup(name: memberFeed.name, 
               profileImage: memberFeed.image,
               isFollowing: memberFeed.isFollowing,
               isLoading: self.loadingStatus[indexPath.row])
    return cell
} else if let photoFeed = feed as? Photo, let cell = tableView.dequeueReusableCell(withIdentifier: PhotoCell.cellIdentifier(), for: indexPath) as? PhotoCell {
    cell.setup(title: photoFeed.title, 
               description: photoFeed.description,
               image: photoFeed.image)
    return cell
} else {
    fatalError("Unhandled feed \(feed)")
}

We can see that there’re functions with more than three parameters. It’s better to have an object wrapping those parameters. Thus, here’s the MVVM to rescue! MVVM helps you encapsulate all UI logic into a simple object.

By turning UI manipulation into object manipulation, we significantly reduce the overhead of the dataSource as well as the ViewController.

Create the ViewModel for cells

Here’s our architecture proposal:

We plan to have two viewModels: MemberViewModel and PhotoViewModel, representing the MemberCell and the PhotoCell respectively. The ViewModel is a canonical form of the UI in a cell. We use bind techniques to bind the properties of the ViewModel to the UI components in the corresponding cell. It means that whenever we change a property of the ViewModel, the bond UI component in the cell changes responsively.

The implementation of the MemberViewModel looks like this:

class MemberCellViewModel {
    let name: String
    let avatar: UIImage
    let isLoading: Observable<Bool>
}

We use a customized object, Observable, as the binding tool. It keeps a generic type value and notifies the change of the stored value to the observer by triggering a closure named valueChanged. The implementation is pretty simple:

class Observable<T> {
    var value: T {
        didSet {
            DispatchQueue.main.async {
                self.valueChanged?(self.value)
            }
        }
    }
    var valueChanged: ((T) -> Void)?
}

If you’re interested in more detail about this binding techniques, please check the brilliant article Solving the binding problem with Swift • Five by Srđan Rašić.

Back to our project, the corresponding MemberCell looks like this:

// In MemberCell.swift
func setup(viewModel: MemberViewModel) {
    // The imange and the name won't be changed after setup 
    profileImageView.image = viewModel.image 
    nameLabel.text = viewModel.name
        
    // Listen to the change of the isLoading property to update the UI state
    viewModel.isLoading.valueChanged { [weak self] (isLoading) in
        if isLoading {
            self?.loadingIndicator.startAnimating()
        } else {
            self?.loadingIndicator.stopAnimating()
        }
    }
}

In the setup(viewModel:) function, we set the UI components on the cell using the information from the viewModel parameter. Besides, we set the valueChanged closure to listen to the value change of the isLoadingproperty. The isLoading becomes “true” when users press on the “+” button on the cell. By using MVVM, we simplify the parameter of the setup function. Moreover, converting the UI logic into object manipulation is of great benefit to more Swift techniques, which would be covered in the following section.

Here we have one more thing to do. In the cell, we use an escaping closure, valueChanged, to notify the cell of the UI update. Basically, the cell is reused when users scroll the table view. The relations between ViewModel and Cell could be represented by the following graph:

Let’s take a closer look at the MemberViewModel 1. In the beginning, the MemberCell A assign a closure to valueChanged of MemberViewModel 1 to observe the value change. When users scroll the table view, the MemberCell A becomes invisible. The instant of MemberCell A then is reused for the following cells. However, since the MemberViewModel 1 will not be released at this moment, the valueChanged of MemberViewModel 1 is still notifying the MemberCell A (which is representing a different feed). That is, the isLoading property of MemberViewModel 1 and MemberViewModel 3 updates the same cell and the glitch happens!

The solution is straightforward:

override func prepareForReuse() {
    super.prepareForReuse()
    viewModel?.isLoading.valueChanged = nil
}

Unregister the observer from the ViewModel to avoid the glitch.

Now, it’s time to clean up the dataSource!

let viewModel = viewModels[indexPath.row]
if let memberViewModel = viewModel as? MemberViewModel, 
   let cell = tableView.dequeueReusableCell(withIdentifier: MemberCell.cellIdentifier(), for: indexPath) as? MemberCell {
    cell.setup(viewModel: memberViewModel)
    return cell
} else if let photoViewModel = viewModel as? PhotoViewModel, 
          let cell = tableView.dequeueReusableCell(withIdentifier: PhotoCell.cellIdentifier(), for: indexPath) as? PhotoCell {
    cell.setup(viewModel: photoViewModel)
    return cell
} else {
    fatalError("Unhandled feed \(feed)")
}

The responsibility of the dataSource now is rather simple: setup the table view with cells’ ViewModels. On the other hand, the detail of setting up the UI components of cells are delegated to the cells. The states of cells are stored in the ViewModel (which is owned by the Controller instead of the ViewController). Isn’t it clearer? 🍸

Actually, there’s still room for improvement! Since we unified the interface of the cell, we can reduce the redundancy by using the Protocol technique!

Use Protocol to Reduce the Redundancy

In the func tableView(tableView:, indexPath:) -> UITableViewCell, there are two setup(viewModel:) function calls, with different types of input view models. We can use a Swift Protocol to create a generic setup function for all kinds of cells. Let’s create a protocol named CellConfigurable:

protocol CellConfiguraable {
    func setup(viewModel: RowViewModel) // Provide a generic function
}

This is a protocol of cells. The cell which confirms the protocol is able to be set up by using a RowViewModel instance. Meanwhile, the RowViewModel is another protocol:

protocol RowViewModel {}
// make view models conform the RowViewModel protocol
class MemberViewModel: RowViewModel {...}
class PhotoViewModel: RowViewModel {...}

The ViewModel conforms RowViewModel is able to be used to set up the CellConfigurable. By using the protocol, we are able to step further to clean up the dataSource:

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    let rowViewModel = self.viewModels[indexPath.row]
    let cell = tableView.dequeueReusableCell(withIdentifier: self.cellIdentifier(for: rowViewModel), for: indexPath)
    if let cell = cell as? CellConfiguraable {
        cell.setup(viewModel: rowViewModel)
    }
    return cell
}

/// Map the view model with the cell identifier (which will be moved to the Controller)
private func cellIdentifier(for viewModel: RowViewModel) {
    switch viewModel {
    case is PhotoCellViewModel:
        return PhotoCell.cellIdentifier()
    case is MemberCellViewModel:
        return MemberCell.cellIdentifier()
    default:
        fatalError("Unexpected view model type: \(viewModel)")
    }
}

Now adding a cell type won’t change the implementation of the func tableView(tableView:, indexPath:) -> UITableViewCell anymore! In other words, the scalability of the dataSource becomes great: the complexity remaining the same no matter how many cells we add!

More Protocol

A similar technique could be used to deal with the cell interaction:

protocol ViewModelPressible {
    var cellPressed: (()->Void)? { get set }
}
class PhotoViewModel: RowViewModel, ViewModelPressible {
    let title: String
    let desc: String
    var image: AsyncImage
var cellPressed: (() -> Void)? // Conform the ViewModelPressible protocol
}

We create a protocol named ViewModelPressible. There’s a required implementation: a closure variable named cellPressed. We then make the PhotoViewModel conform the ViewModelPressible by adding a variable, cellPressed. Conforming the ViewModelPressible means that the ViewModel is able to handle the user-press event.

In the table view’s delegate, we add an implementation of func tableView(_ tableView:, indexPath:):

func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    let viewModel = self.viewModels[indexPath.row]
    if let viewModel = viewModel as? ViewModelPressible {
        rowViewModel.cellPressed?()
    }
}

Now all didSelectRow events are transposed to the corresponding ViewModel. The following example shows the usage:

// When creating the view model
let photoCellViewModel = PhotoCellViewModel()
photoCellViewModel.cellPressed = {
    print("Ask the coordinator or the view controller to open a photo viewer!")
}

Again, we successfully wrap the interaction into a ViewModel object and keep the clarity of the delegate of the table view!

After finishing all those works, let’s wipe the sweat off and zoom the camera out from the table view to the FeedListViewController! 🔭

Handle the business logic separately;

You must notice that the FeedListViewController has one more unrelated job:

1. Setups cells’ UI components such as the nameLabel, the imageView, etc.
2. Records cells’ states, e.g., cellLoadingStates.
3. Make an API call and save the model data.

We need to recruit one more person to do this. Here’s an ideal architecture:

We want to make the FeedListViewController a simple view, and move the business logic to another person: FeedListController. The FeedListController takes the responsibility of making API call and save the data models. We can say that the FeedListController’s responsibility is to deal with the business logic. Based on this idea, let’s create a FeedListController:

// FeedListController.swift
let viewModels = Observable<[RowViewModel]>(value: [])

func start() {
    service.fetchFeed { [weak self] feeds in
        self?.buildViewModels(feeds: feeds)
    }
}

func buildViewModels(feeds: [Feed]) {
    var viewModels = [RowViewModel]()
    for feed in feeds {
        if let feed = feed as? Member {
            viewModels.append( MemberViewModel.from(feed) )
        } else if let feed = feed as? Photo {
            var photoViewModel = PhotoViewModel.from(feed)
            photoViewModel.cellPressed = { [weak self] in
                self?.handleCellPressed(feed)
            }
            viewModels.append(photoViewModel)
        }
    }
    self.viewModels.value = viewModels
}

func handleCellPressed(_ feed: Feed) {
    // Send analytics, fetch detail data, etc
    // Open detail photo view
}

From the snippet above, we can see that the controller doesn’t know the logic of any UI component. Instead, the ViewModel is created here as a middleman between the View and the Controller.

From another point of view, the FeedListViewController becomes:

var viewModels: Observable<[RowViewModel]> {
    return controller.viewModels
}

override func viewDidLoad() {
    viewModels.valueUpdate { [weak self] (_) in
        self?.tableView.reloadData()
    }
    controller.start()
}

func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    return rowViewModels.value.count
}

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    let rowViewModel = self.rowViewModels.value[indexPath.row]
    let cell = tableView.dequeueReusableCell(withIdentifier: controller.cellIdentifier(for: rowViewModel), for: indexPath)
    if let cell = cell as? CellConfiguraable {
        cell.setup(viewModel: rowViewModel)
    }
    return cell
}

func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    if let rowViewModel = rowViewModels.value[indexPath.row] as? ViewModelPressible {
        rowViewModel.cellPressed?()
    }
}

The only responsibility of the FeedViewController is to set up the table view, serve as the dataSource and the delegate of the table view. Adding cell types or modify the interaction won’t change this ViewController.

There are many advantages of doing this: it’s possible to write the unit test to test UI states, the user interaction, as well as the server connection behavior! In addition to the improvement of the testability, the scalability of the whole feed module is also improved!

In this article, we showed how to simplify a complicated table view by doing those changes:

1. Make the cell handles the UI components setup;
2. Use MVVM to abstract the UI components and interactions;
3. Use protocol to consolidate the setup interface;
4. Use Controller to handle to business logic.

Massive View Controller is a notorious anti-pattern. Now we know that the problem is not the MVC pattern itself. There are many ways to separate the responsibilities of your system, including but not limited to the MVVM pattern. I would say the MVVM pattern is a handful tool to improve the code quality, but it’s not a silver bullet. Besides of MVVM, we still need to take care of things such as the scalability, the testability and more principles like SOLID — Wikipedia. So, before adopting any architecture, please thoroughly understand the design of the architecture, carefully select the one that’s best fit your need.

Let’s get our hands dirty and start to craft a better system! 🍻

What to read if you want a deeper dive.

• iOS: How to build a Table View with multiple cell types
• Dealing with Complex Table Views in iOS and Keeping Your Sanity
• Introduction to Protocol-Oriented MVVM
• Clean Table View Code Using Swift Protocols — Jayway

在iOS開發的世界，有個非常有趣，但也非常痛苦的地方，就是iOS的開發者，其實需要的基本知識非常地多，Cocoa framework 本身就涵蓋了前端的UI邏輯，與資料庫等等的後端邏輯，既要注意頁面跟頁面之間狀態的處理，也要小心記憶體的運用，有時候還要學貝茲曲線跟 3D 轉場。雖然每一樣都不可能像各領域的專家一樣精通，但也算是攻城獅裡面武器相當多的種族了。今天，不才小弟要來分享，身為 iOS 工程師，你可能還可以多學的技術：Continous Delivery！身為一個攻城獅，你一定或多或少聽說過 Continous Intgration 跟 Continous Delivery (CI/CD)，但是實際生活中，除非是跟一個團隊一起開發，不然應該很少有機會會碰到 CI/CD 的概念。

所謂的 CI，就是在開發的過程中，我們需要隨時隨地都確保我們的 code 主幹都處在可以一個發佈的狀態。也就是說，不能因為正在開發一個新功能，我們的主幹程式就無法運作或是無法打包新版本。而 CD，指的則是，我們希望在開發的任何一個階段，都要能夠自動化打包出版本，給需要的人使用。誰會是需要的人？在開發的過程中，工程團隊想要手動測試 app 時，就會需要一個 build 來測試，而在開發完畢後，UI測試人員也會需要一個 build 來做測試。最後，在 APP 要上線時，理所當然也會需要一個 build 來送到 iTunesConnect 上以供審核。

所以在系列作拖搞將近三個月後，今天在真實世界的我們，要來介紹一個非常實用的技巧，如何做出一個專供 Apple 生態系使用的 CD 系統，讓你可以每天都提早五分鐘下班(不是很吸引人)。

如果還沒看過系列作的前面幾集，歡迎參考小弟的鍵盤藍綠藻Neo – 來寫一些iOS、技術、與垃圾話，這個系列記載了教科書沒有記載的現實生活開發技術，沒有背景音樂也沒有跑馬燈。

Outline

我們會以下面的步驟來說明如何建立一個好用的 CD 系統，你隨時都可以直接跳到某個章節開始閱讀，也可以直接 End 看電影心得，別擔心，小弟已經開始思考只寫電影心得的可能性。

• 在這個 CD 系統中，我們選擇 XX 而不選 XX 的理由
• 任務簡介與基本的 Project 設定
• 手動化你的 code signing
• 用 Bundler 管理你的系統工具
• 如何設定 fastlane
• 如何設定 Jenkins

開始之前，不是一定，但最好先具備有：

• fastlane 的基本知識
• iOS/macOS code signing 的手動管理經驗
• Jenkins 的基本知識

我們開始吧！

Why not XX

在這個世界上，有成千上萬的公司，運行著成千上萬的工作流程，我們不可能設計出一套系統，同時通用到所有人的工作流程上。所以身為一個系統的建置者，你的任務就是要設計出一個系統，讓它能夠完美地整合進去公司或你個人既有的工作流程中。在這篇文章中，因為篇幅有限（也是因為作者比較懶），我們不可能列出所有可能的設計方式，但是我們會讓你知道，我們每一個選擇的原因，這樣你在實做的時候，就能夠知道那些東西是適合你的，那些不是。

Why Fastlane & Jenkins

Fastlane 是一套熱門的CI軟體，它提供了許多好用的工具，還有直觀的腳本檔，讓你可以不用碰觸到很多系統的細節面，也能夠做到各種客制流程，而且它同時支援iOS/MacOS還有Android平台。大多數的設定你都可以透過 commandline 直接跟Xcode 互動做到，但相信我，你不會想要自己寫那些 script 的XD。目前有些線上的 CI 工具，像是 bitrise，讓你可以用點按的就能夠設定好 CI，但如果你有預算上的限制，並且希望任務也能夠在自己的電腦上運作，那 fastlane 就會是你的最佳選擇。

Jenkins 則是一個有網頁 UI 的自動化排程工具，讓你可以利用 GUI 設定工作內容，像是設定 project 參數等，也可以做到執行排程，像是每日定時任務等。也因為有大量 plugin 的關係，跟很多既有平台的整合也都不錯。其它的選擇也有像是雲端的 CI 系統如 BuddyBuild (恭喜加入 Apple )、CircleCI 等等可以使用，好處是設定更加簡單了，但相對地能客制的部份就比較少，並且因為機器不在我們手邊，遇到比較麻煩的問題也就只能求助 support。對 Jenkins 來說，你除了可以買一台 Mac mini 來架站之外，也可以架在自己的電腦上方便測試，所以這篇我們主要還是以 Jenkins 為主。

Why not match or sigh/cert

你大概已經知道(或者已經很熟悉)，fastlane 提供了許多好用的工具，像是 match 或者是 cert/sigh，來幫我們管理 code signing，但我們這篇並不會使用者些工具，為甚麼呢？自動化的工具的確很方便，但對於大公司或是外包人員來說，首先，並不是所有開發者都有 developer portal 的權限的，很多開發者因為公司政策的關係，只能取得開發者的權限，要修改或是下載 certificate/provisioning profile 都是不行的。這時候 match/sigh/cert 就完全派不上用場了。除此之外，大家應該都有跟 Xcode 裡的 code signing 奮戰的經驗吧？我們希望在 code signing 這邊，越少黑盒子，流程越透明，未來遇到問題的時候，就越容易進入狀況並且找到解決方法。

Our task

假設我們現在正在開發一個 app 叫 Brewer，它每天晚上都會準時釀啤酒，你可以在github上面找到它：

GitHub - koromiko/Brewer: I brew beer everyday :)

我們的工作流程是：

1. 每天一早，工程師要拿到一個最新的 build，來幫同事做簡易的手動測試 (Staging build)
2. 每星期的一開始，也會產生一個 build，讓公司裡的 QA 人員做完整的測試 (Production build)

所以我們的CD系統，要能夠

1. 針對不同的任務切換不同的 build configuration (staging/production)
2. 針對不同任務使用不同的 code signing
3. 把打包好的build送到發佈系統 (Crashlytics, testFlight, etc)
4. 固定時間啟動任務

所以我們會這樣設計我們的 CD 系統：

在圖的最上面，是我們原本的工作流程，就是一般常見的開發、測試、發佈流程。從開發到測試大概的時間是一周。而中間 Delivery 那一列，就是我們的 CD 策略，在開發階段，每一天都會自動釋出一個 nightly build 供開發者做測試，最後在一週的結尾，則會釋出一個版本供 QA 人員做測試。最底下的 Env，指的是我們希望釋出的版本，是運行在怎樣的環境。對開發者來說，我們會頃向用運行在 Staging 環境的版本做測試，這樣可以一直開假帳號、亂買東西也不用擔心弄壞 production。而對 QA 人員來說，他們就會希望能夠使用跟使用者一樣的環境來做測試，所以會在 Production 環境底下建置。最後，在 QA 過後就是 Release 階段，因為 Release 發生的頻率相對不高，並且很有可能沒有一個固定的週期，所以我們會將它設定成手動發佈。在這篇文章中我們只會介紹前兩種設定方法，一旦知道要怎樣設定之後，後面的設定應該都可以得心應手。

接著我們要來了解一下，怎樣透過 Xcode 的 build configuration 做到環境的切換，而不用更改code。詳細的內容可以參考這篇文章 Manage different environments in your Swift project with ease 的第 3, 4 點。簡單地來說，我們會透過 project 的 build configuration 來設定不同的 Flag，做到切換 Staging 版本跟 Production 的效果，我們的 build configuration 設定如下：

針對不同的設定，我們需要設定不一樣的 AppID，這樣的好處是我們可以在測試裝置上同時安裝不同的版本也不用擔心搞混，就發佈系統來說，也比較好管理。

接著我們要來針對不同的 Configuration 做不同的 code signing。

讓 certificate 跟 provisioning profile 回歸你的控制

寫 iOS/macOS 的開發者，應該已經非常熟悉這個畫面了吧！沒錯，我們會第一時間把自動管理憑證關掉，不然你可能會進入自動更新的無間地獄。把自動化關掉之後，就要來準備好所有 code signing 所需要的檔案了，針對我們上面的環境設定，我們需要準備這些檔案：

• Provisioning profile: 針對不同 AppID 的 Ad Hoc distribution profile
• Certificate: Ad Hoc distribution certificate，並且匯出成 .p12

要注意的是，在 developer portal 下載的憑證檔是利用 DEM 加密的 .cer 檔，但 DEM 的檔案裡並沒有包括私鑰，也就是說如果你換電腦了，這張憑證就會因為找不到你的私鑰而失效。所以我們必需要把 DEM 輸出成包含私鑰的 P12 檔，輸出的方法可以參考這篇 stackoverfow。

最後我們把上述的檔案都下載下來，存到另外開的 codesigning 資料夾：

這個資料夾不能跟你的 code 放在一起，它可以放在 jenkins 主機上，也可以做成一個 git repository 或者一個雲端共享資料夾，再利用 fastlane 將這些檔案下載下來使用，好處是不用每次移機時也要手動移動這些檔案。放遠端的作法基本上是安全的，如果你覺得放遠端安全性是有疑慮的，可以參考 match - fastlane docs。

用 Bundler 管理你的系統工具

如果你是 iOS/macOS 開發者，你應該已經很熟悉用 homebrew 來安裝像是 Cocoapods 或是 Carthage 等等套件，homebrew 讓你可以輕易地管理你的系統程式，讓你自己電腦裡面的環境保持一致。但是我們希望我們的建置環境能夠越獨立越好，這樣才不會因為換了電腦建置就會出錯，或者是還要再重覆套件安裝一樣的動作。也就是說我們希望可以製作出一個獨立的環境，可以被完整地複製到不同電腦上，這時候我們就會需要 Bundler。Bundler 是一個 Ruby 的環境管理系統，它可以幫你設定出一個能夠被複製的虛擬環境，之後不管換到任何電腦，對在這個虛擬環境中的程式來說，執行的環境都是一模一樣的。

我們會透過 bundler 管理 fastlane 跟 Cocoapods 的安裝，所以請在 project folder 裡面新增一個 Gemfile 檔案，內容如下：

source "https://rubygems.org"

gem "fastlane"
gem "cocoapods"

Gemfile 是 Ruby 套件管理程式gem的設定檔，裡面描述了你這個project所需要用到的程式。Bundler會透過gem來安裝程式，並且幫你設定好虛擬環境。

接著，我們就可以來安裝這兩隻程式：

bundle install --path vendor/bundler

—path vendor/bundler 表示我們希望把程式安裝在當前的目錄底下，而不是裝到系統檔案夾如 /usr/local/bin 或 usr/bin裡面，這樣你的 project 就不會跟你的系統有任何掛勾了。

請記得將 vendor 這個資料夾加入 .gitignore 之中。

設定完 bundler 之後，未來我們想要在虛擬環境下執行程式的話，就需要下 bundler exec 的前綴，比方說，fastlane init 是初始化一個 fastlane 的 project，現在我們要改成 bundler exec fastlane init，表示我們要初始化一個 fastlane project，並且在剛剛設定的虛擬環境下執行這個指令。

來fastlane一下

fastlane docs 是一個好用的工具，幫助你自動化完成許多繁複的工作。就算你是一人團隊，你也可以透過 fastlane 自動化所有測試、發佈跟憑證管理等等工作。

我們打算利用 fastlane，加入兩個任務，一個是 staging 環境的發佈，一個是 production 環境的發佈。這兩種設定都包含以下固定的工作：

• 從檔案匯入 certificate 與 provisioning profile
• build app 並且上傳到 Crashlytics

兩種設定差別只在於 build configuration 的不同而已，所以我們的 fastlane 要能依據我們所選取的任務，找到對應的 certificate 跟 provisioning profile，用它們來建置 app 並發佈。

在這篇文章中，將以 Swift 設定檔來當範例。選 Swift 來撰寫設定檔，目前 fastlane Swift 是基於 Ruby 的 wrapping，並不是真的原生 Swift，所以 fastlane plugin 是不被支援的，有需要用 plugin 的這點可能要考慮一下。另外，Swift 也無法 catch 任何Ruby 發出來的例外，如果有需要完整的例外處理，就還是請用 Ruby 原生的 fastlane 吧。

安裝方法請參考 Setup - fastlane docs。

安裝完後，我們要先初始化我們的 fastlane project：

bundler exec fastlane init swift

接著，你就可以在fastlane/Fastfile.swift找到你的 fastlane 設定檔。在設定檔裡面，我們可以找到 Fastfile 這個 class，這個 class 裡面所定義的 method，只要是以 Lane 結尾的 method，都會被認定為是一個 "lane"，可以透過 fastlane 來執行。所以我們先新增兩個lane，一個叫做 developerRelease，另外一個叫做 qaRelase：

class Fastfile: LaneFile {
    func developerReleaseLane() {
        desc("Create a developer release")
	package(config: Staging())
	crashlytics
    }

    func qaReleaseLane() {
        desc("Create a qa release")
        package(config: Production())
        crashlytics
    }
}

未來我們想要打包release的時候，都可以執行下面這樣的指令：

bundle exec fastlane developerRelease
# or
bundle exec fastlane qaRelease 

想要打包給 developer 就執行上面的指令，想要打包給 QA 人員，就執行下面的指令，這樣是不是非常地直觀阿！(是)。我們可以看到在這兩個 lane 裡面都會呼叫一個 method：package，並且跟據不同的 lane 給予不同的 config 參數，這個 package 的接口如下：

func package(config: Configuration) {
}

它的參數，其實是一個叫 Configuration 的 protocol：

protocol Configuration {
    /// file name of the certificate 
    var certificate: String { get } 
    
    /// file name of the provisioning profile
    var provisioningProfile: String { get } 
    
    /// configuration name in xcode project
    var buildConfiguration: String { get }
    
    /// the app id for this configuration
    var appIdentifier: String { get }
    
    /// export methods, such as "ad-doc" or "appstore"
    var exportMethod: String { get }
}

所有的 configuration 都要 conform 這個 protocol，才能被傳入 package 裡面做打包。在這個範例裡面，我們設定了兩種 configuration：

struct Staging: Configuration { 
	var certificate = "ios_distribution"
	var provisioningProfile = "Brewer_Staging"
	var buildConfiguration = "Staging"
	var appIdentifier = "works.sth.brewer.staging"
	var exportMethod = "ad-hoc"
}

struct Production: Configuration { 
	var certificate = "ios_distribution"
	var provisioningProfile = "Brewer_Production"
	var buildConfiguration = "Production"
	var appIdentifier = "works.sth.brewer.production"
	var exportMethod = "ad-hoc"
}

跟據實際的狀況，在這兩個struct裡面實作 protocol，這樣可以確保我們的 package 有一致的接口，同時又能符合各種不同的狀況。

接著，我們要開始來實作 package 了。還記得 package 的任務嗎？首先，它需要從檔案引入 certificate 跟 provisioning profile。關於 certificate，我們會使用 importCertificate 這個action，來讀取系統中的 .p12 檔：

importCertificate(
keychainName: environmentVariable(get: "KEYCHAIN_NAME"),
keychainPassword: environmentVariable(get: "KEYCHAIN_PASSWORD"),
certificatePath: "\(ProjectSetting.codeSigningPath)/\(config.certificate).p12",
certificatePassword: ProjectSetting.certificatePassword
)

KeychainName 這個參數就填入你 keyChain 的名稱，keyChainPassword 通常就是你系統的密碼。

因為 fastlane 的設定檔，通常都會跟著原始檔一起被 commit 到 git 裡，把密碼放在 code 裡面，通常不是一個好主意，所以我們會用系統變數來取代固定的字串。在系統上，我們會存入系統變數：

export KEYCHAIN_NAME="KEYCHAIN_NAME";
export KEYCHAIN_PASSWORD="YOUR_PASSWORD";

而在 fastlane 裡面，就利用 environmentVariable(get:) 來讀取系統變數。這樣我們就可以避免把機密字串 commit 到 git 上，大大增加系統的安全性。 接著我們透過 certificatePath 指定 certificate .p12 檔的位置還有這個檔案的密碼。在這裡， ProjectSetting 是一個 enum，存放著 project 相關的變數，我們定義了 codesigningPath 與 certificatePassword，代表所有 code signing 的相關檔案的位置跟密碼，而這些資訊一樣是透過系統變數給予的。

enum ProjectSetting {
	static let codeSigningPath = environmentVariable(get: "CODESIGNING_PATH")
	static let certificatePassword = environmentVariable(get: "CERTIFICATE_PASSWORD")
}

以上 certificate 的引入就設定完畢了！接下來是 provisioning profile 的設定，我們會利用 updateProjectProvisioning，跟據不同的設定檔，來更新 project 的 provisioning profile：

updateProjectProvisioning(
xcodeproj: ProjectSetting.project,
profile: "\(ProjectSetting.codeSigningPath)/\(config.provisioningProfile).mobileprovision",
targetFilter: "^\(ProjectSetting.target)$",
buildConfiguration: config.buildConfiguration
)

config 就是我們一開始代入的 package 的參數，是一個 conforms Configuration protocol 的 struct 或 class。在 profile 這個參數中，我們利用 codeSigningPath 跟`config.provisioningProfile` 來指定 provisioning profile 的位置，我們同時也在 buildConfiguration 這個參數裡指定我們要修改的 build configuration，這樣 updateProjectProvisioning 就會把指定的 provisioning profile 寫入指定的 configuration 裡面了。

注意：這個 action 會直接修改你的 .xcodeproj，對 Jenkis 來說，所有修改都是不會被 commit 的，所以在 CD 系統中這些修改都是沒有問題的，但如果你希望在你的 working directory 裡面執行 fastlane，就要特別留心 .xcodeproj 的修改問題

設定完了 code signing 之後，我們就可以開始來 build 跟 export 了：

buildApp(
workspace: ProjectSetting.workspace,
scheme: ProjectSetting.scheme,
clean: true,
outputDirectory: "./",
outputName: "\(ProjectSetting.productName).ipa",
configuration: config.buildConfiguration,
silent: true,
exportMethod: config.exportMethod,
exportOptions: [
"signingStyle": "manual",
"provisioningProfiles": [config.appIdentifier: config.provisioningProfile] ],
sdk: ProjectSetting.sdk
)

buildApp 這個 action，能夠幫你 build 你的 project，並且輸出 ipa，供上傳或送審。大部份的參數都非常直觀，像 configuration 這裡，可以看出來我們使用 config 物件來指定我們要使用的 build configuration。另外，在 exportOptions 這個參數：

exportOptions: [
    "signingStyle": "manual",
    "provisioningProfiles": [
    	config.appIdentifier: config.provisioningProfile
	] 
]

這個參數的型態是 dictionary，`signingStyle` 指的是你希望使用的 code signing 的方法，這邊必需要設定成 "manual"。再來是 provisioningProfiles 這個參數指定 app id 跟 provisioning profile 的 mapping，也就是那一個 app id 該使用那一個provisioning profile 去 sign，它也是一個 dictionary，key 是 app id，而 value 就是 provisioning profile 的檔案名稱。在這邊我們使用 config.appIdentifier: config.provisioningProfile，來讓這個 mapping 可以由 config 物件決定。

以上我們就完成了從 code signing 到 build 跟 export 的設定了！

現在你可以透過

bundle exec fastlane qaRelease

或是

bundle exec fastlane developerRelease

來輸出針對不同環境建置的 app 了！

以上是利用 fastlane 打包的部份，但別忘了，我們還有定時打包的功能，這個任務，就要交給 Jenkins 來做。

The housekeeper - Jenkins

Jenkins 是一個 CI/CD 的管理系統，幫助你自動化與定期化執行各種不同的任務。它有著憨厚(？)的介面，讓你不用寫一堆 script 就能夠設定好自動化任務。如果你是一個大團隊，建議另外弄一台 mac mini 當做 Jenkins 的主機，所有發佈的任務都在那台主機上運行，這樣可以確保每次出去的版本都不會因為環境的不同而出現不能預期的問題。如果你是一人團隊，那你就把 Jenkins 裝在自己的電腦，或者直接使用 fastlane 做打包就好，沒有 24 小時運行的主機的話，設定定期任務是沒有太大意義的(為了在 build code 時能順順地看 Netflix，我也好想要一台 mac mini)。

Jenkins 在 mac 上安裝非常容易，可以直接透過 dmg 檔安裝，Jenkins installation and setup。另外，我們會需要 git 的 plugin，讓 Jenkins 能夠支援 git 的操作。dmg 安裝會設定一個 mac 的 user: jenkins，它不能登入也不能操作 commandline，也不佔太多空間，純粹就是讓 Jenkins server 有獨立的權限控管。

安裝完之後，我們先來看看，Jenkins 在我們的 CD中，扮演怎樣的角色：

從圖上可以看得出來，Jenkins 扮演著管家的角色，時間一到，它就會負責去 repository 抓最新的原始碼，抓下來之後，開始執行指定的任務，任務內容包括：

1. 設定 environment variables
2. 透過 bundler 安裝 dependency
3. 執行 fastlane 的任務

了解了 Jenkins 的工作之後，我們就可以開始來新增我們的定期任務。先從 nightly build 開始，我們先新增一個 Jenkins freestyle project，並點擊 Configure 進到設定頁面。設定頁面裡有幾個重點我們需要注意：

第一個是 Source Code Management(SCM)，在這邊我們會設定我們 project 的repository URL，還有指定要 fetch的branch，如下圖：

Repository URL 就是設定我們的 github 或其它系統的 repository url，Credentials 則是可以設定你在 repository 的帳號跟密碼，這樣 Jenkins 才能通過授權下載原始碼(如果是 private repository)。Branches to build 可以設定你的目標 branch，以定期任務來說，通常都會設定成你的 default branch。

再往下，我們可以看到 Builder Trigger 區塊，這個區塊是要設定這個任務的觸發點，也就是要設定自動化啟動任務的條件。如果這邊都沒有設定任何 trigger，那任務就是手動觸發。我們的 trigger 設定如下：

我們啟動了一個 Poll SCM，它的意思是，讓 Jenkins 定期向我們的 source code repository 查看是否有更新資料，如果有的話，就啟動我們現在這個 task。設定是一串空白隔開的火星文：

H 0 * * 0-4

這是甚麼意思？讓我們先看一下，關於 Poll SCM 的說明：

This field follows the syntax of cron (with minor differences). Specifically, each line consists of 5 fields separated by TAB or whitespace:
MINUTE HOUR DOM MONTH DOW
MINUTE  Minutes within the hour (0–59)
HOUR    The hour of the day (0–23)
DOM The day of the month (1–31)
MONTH   The month (1–12)
DOW The day of the week (0–7) where 0 and 7 are Sunday.

從說明可以看得出來，這一串字串總共有五個部份，由左到右依序是：

• 分
• 時
• 日
• 月
• 星期幾

我們可以直接指定數字，或者0–59這樣的字串代表有效區間，使用*的話就表示所有可能的數值都會觸發，代表任意一個有效的數字，通常會被用在分的設定上，目地是要把系統上每一個 task 都盡量分散在一小時內運行。所以回到我們剛剛的 schdule setting：

H 0 * * 0-4

表示我們希望任務可以在週日到週四、一年中所有的月份、每天的 0 點不指定分執行，這就是 nightly build 的 schedule。

最後，我們往下可以看到 Build 的區塊，在這裡我們就可以設定當時間一到，要讓Jenkis執行的程式。內容如下：

export LC_ALL=en_US.UTF-8;
export LANG=en_US.UTF-8;

export CODESIGNING_PATH="/path/to/cert";
export CERTIFICATE_PASSWORD="xxx";
export KEYCHAIN_NAME="XXXXXXXX";
export KEYCHAIN_PASSWORD="xxxxxxxxxxxxxx"

bundle install --path vendor/bundler
bundle exec fastlane developerRelease

前面幾行都是在設定 environment 變數，像是 LC_ALL 跟 LANG 主要是要確保fastlane能運行在正確的locale底下，而 KEYCHAIN_NAME、KEYCHAIN_PASSWORD 與 CERTIFICATE_PASSWORD 就是我們在 fasten 設定教學時使用的環境變數。CERT_PATH 是你放置在 Jenkins 主機上的 code signing 目錄的位置。這裡我們會建議使用絕對路徑，經驗上，有時候設定相對路徑在某些 action 上面是無法運作的。 最後兩行則是安裝 dependency 跟真正執行 fastlane 來build你的project。這邊我們可以看得出來，我們的 nightly build task 會執行 developerRelease 這個 lane。

到這邊，我們終於把我們的 nightly build 建立起來了！你可以在 Jenkins 的 project 頁面點擊 build now 來看看你的任務是否有運行成功。

在底下的 Build history，你可以看到每一次 build 的時間與成功或失敗的記錄，點擊 build number 可以看到更詳細的狀態，也可以看到 console 的輸出。這些功能都可以讓你很方便地了解 build 的狀況還有如果發生問題的時候，能夠更快地找到問題並解決。

為甚麼任務一直失敗？

只要是跟系統相關的問題，通常狀況都非常多且複雜，雖然大多的錯誤都可以在 google 上找到解答，但是有時候你得到的錯誤訊息並不是有用的或是相關的。以下有幾點小技巧，讓你在遇到問題時可以更快獲得解答。

Unlock your KeyChain

不管你想把 certificate 存在那一個keychain裡，都要記得解鎖它噢。

想要了解更進階的 keychain 產生技巧，避免動到預設 login keychain，還有減少certificate 被從 keychain copy 出來的風險，可以參考小弟的 github project，裡面的 fastfile 是自動產生 keychain 並且在使用過後刪除 keychain 的範例。

先確保能在 Jenkins 主機能夠 build & export

fastlane 其實是把 Xcode commandline tool 打包成人類比較好理解的語言，所以通常如果不能 build，有很大的機會是因為 Xcode 本身就 build 不過，所以如果 Jenkins 的任務不過，請先不要急著在 Jenkins 的介面上 debug，先在 Jenkins 主機上，透過 commandline build 你的 project，這樣可以得到更多有用的資訊。

xcodebuild clean archive -workspace <your workspace file> -scheme <your scheme>

你可以加上 —verbose 參數，讓輸出的訊息更完整。

fastlane 透過 parse 你的 build setting 來決定要怎樣執成任務，所以如果你想確定 build 設定是不是正確，可以使用以下指令來檢查：

xcodebuild -showBuildSettings -workspace <your workspace file> -scheme <your scheme> -configuration <the configuration you want to check>

當你 achieve 完之後，也可以測試一下是否能夠 export 成功：

xcodebuild -exportArchive \
           -exportFormat ipa \
           -archivePath <ARCH PATH>" \
           -exportPath <IPA PATH> \
           -exportProvisioningProfile "<Provisioning Profile>"

CD 系統的設計原則

以 iOS/macOS 的 CD 系統來說，減少 bug 並且提早下班(或務實一點，準時下班)，通常有幾個要點：

• 減少系統相依性：盡量不要依賴某個系統的程式，像是需要 ruby 的某個版本，或者呼叫某個在 usr/local/bin 的程式。
• 任務跟任務之間不能有相依性：每次的任務都是全新的開始，不能有下次任務用到上次任務產出的資料的情況發生，最好的做法就是執行完任務之後，就把中間產物刪除。
• CD 系統要能夠被很快地複製：就算轉換到不同電腦上，應該也要能夠在裝完 Jenkins 後就直接被執行，像是把跟 project 無關的設定，如 path 跟 password，都移到 environment variables，這樣任務出錯時，我們就能夠把專注力放在我們的程式，而不是某個主機的設定上。

最後，你也可以參考 fastlane 的 troubleshooting，這裡面有許多有用的資訊：Troubleshooting - fastlane docs。 可以看到，大多數的問題，都是萬惡的 code signing 引起的，iOS 工程師通常會在一天的一早開始處理不能 build 的問題，並且在下班前五分鐘發現原來是用到了舊的 certificate，然後流著淚在公司加班。

Summary

雖然 iOS/macOS 工程師，有很大一部份都是一人團隊，所以所謂的 delivery 也就是 archive 後，直接點 Crashlytics 的 distribute 就送出了。但是就算是一人團隊，透過一個自動化系統，就能夠把 build 任務分攤到別的主機，減少 build 時切換環境發生的錯誤，還是非常值得投資的。更不用說在多人團隊，跟 workflow 結合的 delivery system，能夠帶來的好處就更多了。如果你不喜歡寫 script 或跟系統打交道，目前 Apple 生態系的 CD 系統其實也非常蓬勃，包括個人覺得相當好用的 bitrise、很多人都在使用的 CircleCI、還有被 Apple 買走的 Buddybuild（期待apple原生的CD環境），都是非常可以考慮的選項。這篇文章主要著眼在了解如何透過 fastlane 跟 Jenkins 建置簡單的 CD 系統，如果你都了解的話，一定可以設計出一套符合你目前團隊工作流程的 CD 系統的！

好了，前情提要真的太久了，本文開始。

Black Mirror

身為一個反烏托邦腦粉，一定要推薦一下這部反烏托邦經典影集：Black Mirror。這是一部英國的影集，目前已經出到第四季，每一集之前完全沒有連貫，都是自成一格的獨立故事，也就是說你可以隨時從隨便一集開始看都沒關係。每一集都會描述一個科技或制度非常極端的世界，像是能夠讓人分不清真實或虛擬的 VR，或者一個能夠把一輩子看過的東西全部都錄下來的隱型眼鏡，透過這種極端的設定，來讓我們看到現在社會上某些方便的科技或法律可能帶來問題跟隱憂。每一集大概都一小時，製作精美的像電影一樣，劇情通常也是完全不會沉悶(除了反思的時候常會覺得人生無望XDDD)，是評價跟閱覽數都相當高的影集。 Men Against Fire 是第三季的第五集，是第三季裡面個人覺得最好看的一集(第六集是最受歡迎的一集)，雖然很想介紹內容，但是一介紹就爆雷了，所以請大家先去看影片，看完再回來敲碗(也就是拖稿)。最後提醒，大家可以透過Netflix觀看到這部影集喔，也請 Netflix 如果覺得你們的流量上升，那應該是因為小弟也有貢獻一、兩個導流，就給小弟一點業配謝謝！XD

在上一篇文章中，我們介紹了一個新的架構：Model-View-ViewModel(MVVM)。透過MVVM pattern，我們把business logic跟presentational logic從ViewController裡面抽出來，變成一個單純好測試的物件。但是對於如何做測試，卻是支字不提，不要懷疑，這就是拖稿(?)。在這篇文章裡，我們就要來看看，怎樣針對我們的ViewModel來寫Unit Test。

最近APP架構又成為大家熱門的話題，有很多有趣的文章都在針對這種百家爭鳴的iOS app架構現象提出檢討。其中Much ado about iOS app architecture這篇還不錯，大家可以看看。雖然像是MVVM、VIPER、Clean這些架構的目地都是要解決app架構上權責不分、不易測試等等問題，但是很容易被當成Silver Bullet，以為只要套用了這樣的全新架構，code從此就變得閃亮亮，bug也都自然消失了。另一方面，也有很多人因為這些架構的某些挶限，而完全否認這些架構所帶來的好處(簡單、易上手等等)。

在軟體的世界，真的沒有所謂的好壞，只有適不適合。對IQ不高的小蛇我來說，在沒有人手把手地教你的情況，跟本很難在短時間達到這些人說的MVC好棒棒的境界，有太多Pattern、太多的法則要去熟練，更不用說要得心應手地應用了。MVVM的好處是它相對簡單很多，並且要從既有的code改寫成MVVM也不是非常難的事情，MVVM在從0開始的情況下，就非常有價值。但如果團隊神人很多，有老練的架構師或是資深工程師在天天幫你看code，MVVM就不一定適合你，團隊原本在用的架構跟原則反而才會是最適合的。

Btw, 為了寫文章，小蛇我每個月都要逼自己至少會看一部電影，才有辦法寫出心得來(甚麼理由)。所以想看電影推薦的朋友，不要遲疑，直接End就對了！(也太快放棄抵抗)

TL; DR

在這篇文章中，我們會提到兩個測試的小技巧：

• 如何設計mock來模擬不同的網路狀況
• 如何利用stub建立能夠被測試的資料狀態

利用這兩個技巧，我們可以幫我們的ViewModel建立很完整的測試。

A simple gallery app

回顧一下上次我們的simple gallery app，它具有以下的功能：

1. 會從500px API抓取熱門相片，並且把相片排成列表show出來，每張相片都會顯示標題、描述、跟拍攝日期。
2. 如果使用者點選了非賣品，app就不會讓使用者進到下一頁，並且跳出錯誤訊息。

我們把最一開始的這個頁面稱作PhotoList，它的互動流程會像下面這樣：

其中APIService負責網路層的溝通，像是設定URL、設定request body等等。而PhotoListViewModel則會跟APIService要資料，並且把要到的資料整理一下，轉換成能夠讓View綁定的各種interfaces，也會接收使用者的動作，做出相對應的反應。PhotoListViewController就是單純的View，負責將ViewModel的資料在View上面呈現出來。

在這篇文章裡，我們將會針對三個不同的use cases做測試：

1. 要能啟動APIService上網抓資料
2. 網路層出錯的時候，要顯示錯誤訊息
3. 當使用者點擊for sale的照片時要允許跳到下一頁

MVVM and Dependency Injection

回顧一下我們PhotoListViewModel的設計：

https://gist.github.com/koromiko/1ef41d1d7d87beac22eaf4cc4a38ec69

可以看到，apiService這個物件負責跟server拿資料，並且將拿到的資料回傳給PhotoListViewModel使用。我們利用Dependency Injection(DI)的技巧，將跟網路層有關的工作，全部都交給apiService去做。這個apiService在跑正式的code時，會放上真的APIService物件，讓它真的上server去抓資料。另一方面，當我們在跑測試時，就用被換成假的MockAPIService物件。這樣的好處是在跑測試時，除了可以不用真的把request打上server之外，我們也可以利用MockAPISerivce來看看我們的PhotoListViewModel是不是真的有正確地工作。它們之間的關係可以用底下這張圖來理解：

對DI不熟的話，就讓小蛇來業配一下(自己業配自己？)，可以參考拙作歡迎來到真實世界 – Unit Test for Networking，裡面有詳細的DI技巧介紹。

Behavior test

所以我們的MockAPIService需要滿足下列兩個需求：

1. 要能確定PhotoListViewModel是否真的呼叫了某隻function
2. 要能夠指定不同的狀態，來模擬真實的server行為

先來看需求1.，針對需求1.，我們可以做出這樣的Mock：

https://gist.github.com/koromiko/62522e79c2c73cd2c4b92edf96d47e56

讓我們來好好看一下這個Mock。首先，它符合APIServiceProtocol，所以它完全能夠取代真正的APIService，被放到PhotoListViewModel裡面。接著，可以看到裡面有個property： isFetchPopularPhotoCalled，這個property預設是false，但會在APIServiceProtocol.fetchPopularPhoto被呼叫時變成true，這個設計的用意在於，我們可以透過這個isFetchPopularPhotoCalled，來知道fetchPopularPhoto這個function是不是真的有被呼叫到。

利用這個簡單的Mock，我們就可以來寫我們的第一個測試：

https://gist.github.com/koromiko/1165c644b0b575b96d7203cfc2fc17b4

這段程式碼翻成白話文就是：我想要知道，在sut.initFetch()之後，APIServiceProtocol. fetchPopularPhoto是否有被確實地執行。利用這個技巧，我們就可以測試ViewModel跟它的dependency objects之間的互動了。

Success or Failure?

除了測試我們的ViewModel是不是有確實呼叫fetchPopularPhoto之外，更重要的是，我們想知道當api request成功或失敗時，我們的PhotoListViewModel是不是有正確地處理這些狀況，也就是第二個需求：mock要能夠指定不同的狀態，來模擬真實的server行為。所以我們MockAPIService需要能夠聽從我們的指令，當我們希望它成功，它就要成功，當我們希望它失敗，它就要乖乖地失敗，這就是人在屋簷下，不得不低頭(可以這樣隨便亂用？)。

在這裡，我們先從test code開始看起。剛剛我們有個use case是這樣的：

1. 網路層出錯的時候，要顯示錯誤訊息

根據這個case，我們可以寫出這樣的測試code：

https://gist.github.com/koromiko/37d772b81c62bae16c82bb13b9ed0f7a

我們會先觸發initFetch，讓PhotoListViewModel透過APIServiceProtocol上網去抓資料。然後在mockAPIService.fetchFail(error: error)這裡，我們將mockAPIService設定成一定會回傳失敗，並且指定好錯誤的類型。最後我們會驗證PhotoListViewModel是否有設定好對應的錯誤訊息。這個可以直接指定錯誤類型的mock讓你可以很輕易地模擬各種正確或錯誤情況，並且看看你的物件是不是正常功能中，是不是很方便呢？(是)

接著我們來看看這樣的mock要怎麼設計。先來回顧一下我們的PhotoListViewModel.initFetch()：

https://gist.github.com/koromiko/26bd480bbaec34a5a5736a9a05318aec

initFetch會先啟動apiService的fetchPopularPhoto，並且設定好callback closure，等待apiService完成工作呼叫callback closure，再做對應的處理。所以我們如果在MockAPIService要模擬失敗的API request，就要從這個callback closure下手！

最後我們就實作出了這樣的MockAPIService：

https://gist.github.com/koromiko/ddce82f819d5ea941f99f25265af5788

從上面的程式碼可以看到，當MockAPIService.fetchPopularPhoto被呼叫時，會先把callback closure存下來:

completeClosure = complete

等到MockAPIService.fetchSuccess或MockAPIService.fetchFail被呼叫時，才會觸發callback。在我們還沒呼叫fetchSuccess或fetchFail之前，PhotoListViewModel的callback是不會被呼叫的。這樣就完成了一個簡單的非同步、不同狀態的模擬。這樣的效果就如同上面的test code一樣，我們可以透過呼叫fetchFail並指定error object來模擬api request失敗的狀況。

Stubs for ViewModel

我們的ViewModel，除了提供各種properties讓View作資料的綁定之外，也提供接口讓View能夠把使用者的行為傳回來，並且做出相對應的改變，來讓View產生變化。這樣的行為，我們要怎樣做測試呢？一樣，我們先從use case開始看起：

1. 當使用者點擊for sale的照片時要允許跳到下一頁

依照上面的use case，我們寫了以下的test code：

https://gist.github.com/koromiko/d5fa15c50eb3f3627cc6389202eb109f

這段test code代表的意思是，當使用者按下第一個cell時，我們要測試allowSegue是否為true。這段code有兩個問題：

• ViewModel在還沒initFetch之前都不會有資料，所以這樣會觸發exception
• 我們預設了IndexPath(row: 0, section: 0)的photo是for sale了，但事實上它是空的

這時候，stubs就可以派上用場了！Stubs在測試的設計上代表的是一些預先準備好的資料，詳細的定義可以再參考拙作(無孔不入吧！)。為了解決沒有資料，但是又不能真的連上server去取資料的狀況，我們必須要設計一些stubs來騙過我們的PhotoListViewModel。所以現在來幫我們的MockAPIService做點修改，讓它可以回傳設計好的stubs：

https://gist.github.com/koromiko/c619cbacb3d586e7dffe59277563cf20

其中completePhotos這個property就是我們放置stubs的地方，只要在這邊指定好Photo objects，在呼叫MockAPIService.fetchSuccess時，completeClosure就會把completePhotos裡面的內容回傳給PhotoListViewModel。再回到我們的test code，我們現在把test code修改成這樣：

https://gist.github.com/koromiko/1e145c3409b158f4fea4a174a789f64b

我們先把準備好的Stubs：StubGenerator().stubPhotos(), 丟到mockAPIService.completePhotos裡面，接著觸發PhotoListViewModel的initFetch，這時候PhotoListViewModel會去跟mockAPIService要資料，然後我們再透過呼叫mockAPIService.fetchSuccess()，來讓stubs回傳給PhotoListViewModel，完成資料的準備。

這樣一來，我們在test code裡面呼叫sut.userPressed(at: indexPath)就沒有問題了，因為這時候PhotoListViewModel的狀態就會是已經截取完資料，並且因為stubs是我們在測試時一併放進去的，所以我們也知道我們正在測試的photo是不是for sale了。

More tests and more todos

這個小app還有更多的測試，有興趣的可以參考小弟的原始碼：

Tutorial/MVVMPlayground at master · koromiko/Tutorial · GitHub

裡面包含了這些test case：

1. 要能啟動APIService上網抓資料
2. 抓資料的時候要正確顯示讀取動畫
3. 網路層出錯的時候，要顯示錯誤訊息
4. cell數量要正確
5. cell內容要正確
6. 使用者點擊for sale的照片時要允許跳到下一頁
7. 使用者點擊not for sale的照片時不能有動作並且要顯示錯誤訊息

可以看到，在MVVM的架構底下，我們寫的測試可以幾乎涵蓋整個模組，包括presentational logic還有各種複雜的state都能夠被測試到。這就是MVVM的好處，它容易上手並且不會有太多的boilerplate。

相對的，我們的這個測試小app也有很多待改善的點，像是View這一層完全沒測試，ViewModel的工作太多，還有關於ViewModel倒底應該stateless還是要有完整的state以方便測試，這些點都是未來可以改進的目標。這個系列未來會一步一步地refactor這個小app，歡迎訂閱小蛇的blog，一起來研究怎樣寫出更棒的app吧！

Recap

在這個簡單的分享裡面，我們透過設計好的MockAPIService，來模擬各種現實生活中會發生的情形，並且讓測試的code能夠完整涵蓋各種狀況。這個MockAPIService的任務主要有：

• 記錄SUT是否有確實與它互動
• 記錄SUT傳進去的資料是否正確
• 模擬各種不同的狀態

透過這個Mock，加上MVVM把presentational logic從ViewController裡面拆分出來的特性，我們就可以成功地完成所有use case的測試了！

還是要強調，沒有silver bullet，到這邊只是一開始而已，小蛇我也還在學習當中！歡迎大大們給予各種建議，也歡迎加入討論，覺得那邊觀念有錯或是程式有錯也歡迎提出來喔！

我的FB都在喇賽XD，所以想看技術相關的，請follow小蛇的Twitter: https://twitter.com/KoromikoNeo

最後進入本文XD

從很小的時候開始，這個畫面就是心中未來世界的代表，如果你問我未來世界長怎樣，我就會照著這個場景描述給你聽。到現在我還是能夠回想第一次看到這個場景設定的感動，也因為這部電影讓我開始喜歡cyberpuck，覺得那種用舊技術銓釋的未來十分迷人。

這部就是1982年的Blade Runner(銀翼殺手)

不過這部片在對話、敘事、還有邏輯的處理真的有待加強，bug超多，角色刻畫不深，還有很多如果沒有後人的解釋跟本連想像空間都沒有的晦澀對白，相較之下更單調的2001 Space Odessey反而在說故事方面略勝n籌XD

所以小蛇真正推薦的是Blade Runner 2049 XD

完全可以撐起原作甚至以說故事的能力來說還比前作強大，雖然以現代的眼光來看這種到處都是刻意雕琢的畫面及劇本，還有已經不算前衛影像風格可能已經不那麼吃香，但是因為它是Blade Runner的續作，所以看起來只有滿滿的感動 (已經無法中立評論XD) 總之請在看2049之前一定要看過1982或至少知道前作的故事，然後喜愛cyberpunk的記得去電影院看，雖然說現在只剩台北冷門時段有了XD
這部在IMDB拿到8.4高分的電影在票房上倒是有點悽慘，實在很可惜，科幻片在這個年代已經是復古的存在了XDDD

Introduction

Once an idea has taken hold of the brain it's almost impossible to eradicate. - Cobb
一旦某個想法掌握了你的腦袋，它將會變得難被鏟除。-Cobb

Inception(全面啟動)一直都是個人最愛的電影之一，劇情燒腦、世界觀完整、畫面夢幻，而且又是這種穿越虛實的題材，幾乎所有元素都深得我心。

進入夢境就電影來說不算太新的梗，Inception跟其它夢境電影不一樣的是，進入夢境有個更複雜的原因：要徹底改變某個人的想法。老梗電影如果進入某人的夢境，很有可能就只是要引出一些秘密，像是金庫密碼之類的(腦海中馬上浮現：左三、右二、左一)，但是在Inception裡，進入別人的夢境是為了要改變某人的想法，讓他乖乖地聽話做一些很蠢的事。這點其實非常的有趣，在生活中，的確有些想法根植在腦海中，久久揮之不去，就像被誰植入了思想一樣，比方說戈巴契夫頭髮最多、海珊最不愛打仗，到長大後我還是一直深信不移。

所以這跟我們今天的主題有甚麼關係呢？非常有關係！因為從上篇文章開始，內容就一直都圍繞著一個主題：我最喜歡的電影...阿不是，是如何在iOS上做乾淨的、與真實環境互相獨立的單元測試。

在上次介紹完Depedency Injection之後，想必大家應該都很了解如何在自己的模組裡，把現實環境抽掉，植入一個假的環境了。如果還不是很清楚Depedency Inject在測試上的應用，可以參考拙做：歡迎來到真實世界 - Unit Test for Networking(https://www.codementor.io/koromiko/unit-test-for-networking-ahdpdqr5k)。

接下來，我們會延續上次的主題，繼續來探討需要跟真實世界互動的元件的Unit Test。在這篇文章，我們主要研究的題目是：怎樣做Core Data的Unit Test。

Core Data是一個iOS上面資料結構的封裝，它把跟資料庫相關的邏輯都封裝起來，並且提供大量高階的方法，讓你盡量避免在儲存資料時，還需要把資料庫邏輯跟商業邏輯都寫在一起，讓存取資料變的更直觀。如果要順利地閱讀這篇文章，需要的背景知識就是Core Data的基本運作原理、Core Data的concurrency等。如果不太了解Core Data的運作，可以參考一些教學文章：

A Complete Core Data Application · objc.io(https://www.objc.io/issues/4-core-data/full-core-data-application)

An Introductory Core Data Tutorial - Cocoacasts(https://cocoacasts.com/core-data-tutorial/)

TL;DR

這篇文章會包含以下主題：

• 使用NSPersistentContainer建置Core Data stack
• 設定In-memory Persistent Store
• 基本測試技巧：Fake、Stub
• 在XCTestCase內做非同步的測試

Requirement

這篇文章中使用的開發環境為：

• Swift 3
• iOS 10
• Xcode 8

因為我們會使用NSPersistentContainer來設定Core Data Stack，所以iOS 10是必要的。

Our task

今天我們的目標是要實做一個簡單的todo list系統，可以新增、讀取、修改、刪除(CRUD, create, read, update, delete) todo list，我們希望這個系統，可以在關掉app再打開之後，還能繼續記得上次修改的資料。沒錯，這個todo list app比腦袋還強！

所以我們的任務來了，我們需要一個系統可以：

1. 新增一個Todo
2. 取出所有Todo
3. 刪除一個Todo
4. 把暫存的資料推進persistent store

因為手機上資源有限，我們不希望每次存取都動到真的資料庫，而是要在真的有需要的時候，才把資料寫入資料庫，所以我們在設計這個系統的時候，會把儲存資料這件事抽出來（第4點)，讓它可以納入商業邏輯的考量之中，未來就可以視情況，看是要讓使用者按下儲存後才真的儲存，或是資料累積到一定的量才儲存。

Core Data在iOS 10之後，其實已經大幅簡化了設定難度，以往需要寫一大堆boilerplate的狀況已經不復見了，在使用上也不一定需要很深入的了解，就能夠做基本的操作。雖然話是這麼說沒錯，但如果能夠了解整個Core Data stack，還有各個元件互動的方式，對於設計模組跟寫測試還是有一定的幫助的，所以下面這個小節，會簡單提一下Core Data stack裡面有那些元件，還有這些元件是怎樣互動的。

Core Data stack

Core Data stack是整個Core Data的基本架構，描述Core Data在運作時，有那些元件，這些元件各自會有那些任務等等。

根據Apple的文件(https://developer.apple.com/library/content/documentation/DataManagement/Devpedia-CoreData/coreDataStack.html)，Core Data Stack分成下面幾個部份：

• Managed Object Context (NSManagedObjectContext)，提供不同的運行環境給managed objects。
• Persistent Store Coordinator (NSPersistentStoreCoordinator)，負責整合每個Data Stores。
• Managed Object Model (NSManagedObjectModel)，負責描述資料的結構、長相等等。
• Persistent Object Store，負責底層的資料庫寫入跟讀取等。

Core Data stack(https://developer.apple.com/library/content/documentation/DataManagement/Devpedia-CoreData/coreDataStack.html)

以往要設定好這個stack，需要寫非常多的code來個別設定。而在iOS 10之後，官方提供了一個新的類別：NSPersistentContainer，把上面整個stack都打包起來，現在只要初始化一個NSPersistentContainer，並且代入一些參數，接下來所有操作都可以圍繞在這個container上面就好，相當方便。

設定環境

知道了Core Data stack是怎樣的東西之後，我們就要來設定我們的Core Data環境。如果你是在啟動Project時，就勾選Use Core Data，那Xcode會自動幫你在AppDelegate裡面產生必要的code，但如果你是後來才加的，記得要在AppDelegate裡面設定好container：

lazy var persistentContainer: NSPersistentContainer = {
		let container = NSPersistentContainer(name: "PersistentTodoList")
		container.loadPersistentStores(completionHandler: { (storeDescription, error) in
			if let error = error as NSError? {
				fatalError("Unresolved error \(error), \(error.userInfo)")
			}
		})
		return container
	}()

一般來說一個App只會有一個persistent store，這也就是為甚麼我們需要一個全域的container，目的就是為了方便讓其它class取用相同的container，而不會造成混淆。

一個基本的Todo list，至少要能夠寫上要做的事項，並且要能標示是否完成，所以我們的Data Model需要描述一個具有以下attributes的entity：

• name (string)
• finished (bool)

所以設定上會長這樣：

設計TodoStorageManager

設定完Core Data stack之後，我們可以開始來設計我們主要拿來操作Core Data的類別：TodoStorageManager，這個manager的功用，就是負責所有跟Core Data的互動，簡化操作的細結，讓資料處理可以盡量獨立於其它邏輯之外。我們目前規劃的功能，就是簡單的CRUD。

因為這個manager主要操作的環境就是Core Data，所以我們的dependency自然而然就會是persistent container，初始化設定如下：

class ToDoStorgeManager {
	
	let persistentContainer: NSPersistentContainer!
	
	//MARK: Init with dependency
	init(container: NSPersistentContainer) {
		self.persistentContainer = container
self.persistentContainer.viewContext.automaticallyMergesChangesFromParent = true
	}
	
	convenience init() {
		//Use the default container for production environment
		guard let appDelegate = UIApplication.shared.delegate as? AppDelegate else {
			fatalError("Can not get shared app delegate")
		}
		self.init(container: appDelegate.persistentContainer)
	}
}

上面設定了一個convenience init，放入預設的dependency，也就是全域的container，這樣一來在production環境要取用這個manager會比較簡單，也比較容易在看code時候就知道它的功用。

另外，我們希望在操作Core Data時，寫入在背景thread執行，這樣可以避免效能上的問題。在NSPersistentContainer裡，預設會提供兩種context：viewContext跟backgroundContext。viewContext就是運行在main thread上的context，而利用NSPersistentContainer.newBackgroundContext()產生的context，就是backgroundContext，會在背景thread執行資料庫操作。

在這邊我們預設我們的背景任務(所有寫入的任務)都只需要在同一個背景thread執行，所以我們會直接建立一個backgroundContext供使用：

lazy var backgroundContext: NSManagedObjectContext = {
		return self.persistentContainer.newBackgroundContext()
}()

最後，操作的部份實作如下：

//MARK: CRUD
func insertTodoItem( name: String, finished: Bool ) -> ToDoItem? {

	guard let toDoItem = NSEntityDescription.insertNewObject(forEntityName: "ToDoItem", into: backgroundContext) as? ToDoItem else { return nil }
	toDoItem.name = name
	toDoItem.finished = finished
	
	return toDoItem
}

func remove( objectID: NSManagedObjectID ) {
	let obj = backgroundContext.object(with: objectID)
	backgroundContext.delete(obj)
}

func fetchAll() -> [ToDoItem] {
	let request: NSFetchRequest<ToDoItem> = ToDoItem.fetchRequest()
	let results = try? persistentContainer.viewContext.fetch(request)
	return results ?? [ToDoItem]()
}

func save() {
	if backgroundContext.hasChanges {
		do {
			try backgroundContext.save()
		} catch {
			print("Save error \(error)")
		}
	}	
}

到這裡，最簡單的manager就寫完了，它現在可以新增、讀取跟刪除todo item了。

Unit Test Setup

接著我們要開始來撰寫測試的code，依照我們的規劃，我們需要以下幾個測試case：

1. 要能成功新增Todo並回傳ToDoItem物件
2. 要能取得目前資料庫中的todos
3. 要能成功刪除資料庫中的todo
4. 呼叫save()，要能夠對資料庫執行Save

確定了我們的目標之後，我們就可以開始來設置我們的測試了，首先我們先設定好我們的SUT：

var sut: ToDoStorgeManager! 
override func setUp() {
	super.setUp()
	sut = ToDoStorgeManager(container: mockPersistantContainer)
}

其中mockPersistentContainer就是一個mock container，我們想要拿它來取代真的container。對Core Data來說，persistent store應該要是sqlite或是binary store，這樣才能把資料永久儲存下來。問題是，這兩樣都是我們目前無法mock的東西，所以我們需要利用不一樣的測試技巧，來達到替換環境的目的。

Fake - In-memory data store

Core Data本身有提供一種特別的store type：NSInMemoryStoreType。這個NSInMemoryStoreType，對Core Data來說，也是一種persistent store，跟sqlite或是binary不一樣的地方是，這個store的資料，只會儲存在記憶體裡面。也就是說只要App一關掉，所有的資料就會消失。我們可以利用這樣的特性，來做一個假的、只存在記憶體裡面的store，讓unit test code可以自由取用，又不用擔心資料跟production的搞混。這種方法，通常在測試技巧裡面被稱做為：Fake，也就是透過製作一個非常接近真實環境的物件，來讓測試能夠盡可能與真實隔離，但又能像是在真實環境中執行一樣。

Objects actually have working implementations, but usually take some shortcut which makes them not suitable for production - Martin Fowler

所以我們就利用這個假資料庫，來製作我們的mock container吧！

lazy var mockPersistantContainer: NSPersistentContainer = {

	let container = NSPersistentContainer(name: "PersistentTodoList", managedObjectModel: self.managedObjectModel)
	let description = NSPersistentStoreDescription()
	description.type = NSInMemoryStoreType
	description.shouldAddStoreAsynchronously = false // Make it simpler in test env
	
	container.persistentStoreDescriptions = [description]
	container.loadPersistentStores { (description, error) in
		// Check if the data store is in memory
		precondition( description.type == NSInMemoryStoreType )

		// Check if creating container wrong
		if let error = error {
			fatalError("Create an in-mem coordinator failed \(error)")
		}
	}
	return container
}()

讓我們來仔細分析一下裡面的內容：

let container = NSPersistentContainer(name: "PersistentTodoList", managedObjectModel: self.managedObjectModel)

這行會初始化一個container，並且指定managedModel。因為在我們的test target裡面，namespace跟production target是不一樣的，如果我們不指定managedModel，NSPersistentContainer會無法抓到我們的的managedModel，也就是.xcdatamodeld檔案。所以這邊我們必須要手動讓test code先抓到那個.xcdatamodeld，然後餵進container裡面，如此一來才能夠共享同樣的database schema。這個managedObjectModel設定如下：

lazy var managedObjectModel: NSManagedObjectModel = {
	let managedObjectModel = NSManagedObjectModel.mergedModel(from: [Bundle(for: type(of: self))] )!
	return managedObjectModel
}()

直接透過bundle把managedObjectModel抓進test target使用，而不仰賴NSPersistentContainer的自動判斷機制。另外，因為預設.xcdatamodeld是不會compile進test target的，所以我們也需要把.xcdatamodeld這個檔案加到test target裡面：

接下來，就是這個Fake的關鍵：

let description = NSPersistentStoreDescription()
description.type = NSInMemoryStoreType

container的屬性，可以透過NSPersistentStoreDescription來指定，所以我們就把我們的store設定成是InMemoryType，現在，對這個container的操作，就像在夢境裡一樣，不管你怎樣做，都不會影響真實世界了！

Stub - Canned responses

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. - Martin Fowler

根據Martin Fowler的定義，stub就是一些已經寫死的罐頭回傳值，常見的使用情境是：我要測試我的parser正不正確，我就先準備好一份raw data，讓它通過parser，最後比對出來的結果跟我準備的資料有沒有對應。在我們的這個case，我們利用stub，來測試我們對資料庫的操作，是不是有真的在進行，也就是，我們準備一些stubs，把它們塞進剛剛的假資料庫中，因為我們已經預先知道資料庫中有那些資料了，接下來我們就可以測試執行新增是不是真的會多一筆資料，刪除是不是會少一筆資料等等。以下是我們產生Stub的方法：

func initStubs() {
	
	func insertTodoItem( name: String, finished: Bool ) -> ToDoItem? {
		
		let obj = NSEntityDescription.insertNewObject(forEntityName: "ToDoItem", into: mockPersistantContainer.viewContext)
		
		obj.setValue("1", forKey: "name")
		obj.setValue(false, forKey: "finished")

		return obj as? ToDoItem
	}
	
	_ = insertTodoItem(name: "1", finished: false)
	_ = insertTodoItem(name: "2", finished: false)
	_ = insertTodoItem(name: "3", finished: false)
	_ = insertTodoItem(name: "4", finished: false)
	_ = insertTodoItem(name: "5", finished: false)
	
	do {
		try mockPersistantContainer.viewContext.save()
	}  catch {
		print("create fakes error \(error)")
	}
	
}

在這邊，我們直接操作資料庫，放進五筆資料，當作我們的stubs。需要注意的是，因為namespace不同的關係，我們的insert跟edit都不能直接使用ToDoItem，也就是不能用Xcode自動產生的NSManagedObject subclass，而是要用最原始的操作Core Data的方式：用NSManagedObject.setValue(, forKey:)來存取資料，不然會發生找不到entity的問題。偉哉Xcode！另外，這邊使用viewContext來做寫入，是因為我希望讓這個寫入是同步的，要確保這些Stub在test case執行前，就已經產生好並且放入資料庫。

再來，對Unit Test來說，每跑一個test case，都要像是展開新的人生一樣，要是全新的空白的。小魯的人生是黑白的，而測試更慘，只能是空白的。千萬不能出現這個test case被上一個test case影響的狀況，這點非常重要，所以我們要有一個能夠把資料全部清掉的方法：

func flushData() {
	let fetchRequest:NSFetchRequest<NSFetchRequestResult> = NSFetchRequest<NSFetchRequestResult>(entityName: "ToDoItem")
	let objs = try! mockPersistantContainer.viewContext.fetch(fetchRequest)
	for case let obj as NSManagedObject in objs {
		mockPersistantContainer.viewContext.delete(obj)
	}
	try! mockPersistantContainer.viewContext.save()
}

這邊一樣，不能對ToDoItem這個自動生成的class做任何操作，所以我們使用最原始的方試操作Core Data，再跟我念一次，偉哉Xcode~

把這兩個方法加到setUp()跟tearDown()之後，我們就可以確保每個test case都是嶄新的開始了！

override func setUp() {
	super.setUp()
	initStubs() // Create stubs
	sut = ToDoStorgeManager(container: mockPersistantContainer)
}

override func tearDown() {
	flushData() // Clear all stubs
	super.tearDown()
}

Test Cases

經過了長時間的鋪陳，終於要進入我們的主菜了，主菜相對很簡單，只要跟隨 Given, When, Assert這樣的模式，就可以順利寫出每個test case，以下我們先把新增、讀取、跟移除的test case寫完：

func test_create_todo() {
	
	//Given the name & status
	let name = "Todo1"
	let finished = false
	
	//When add todo
	let todo = sut.insertTodoItem(name: name, finished: finished)
	
	//Assert: return todo item
	XCTAssertNotNil( todo )

}

func test_fetch_all_todo() {
	
	//Given a storage with two todo
	
	//When fetch
	let results = sut.fetchAll()
	
	//Assert return two todo items
	XCTAssertEqual(results.count, 5)
}

func test_remove_todo() {
	
	//Given a item in persistent store
	let items = sut.fetchAll()
	let item = items[0]
	
	let numberOfItems = items.count
	
	//When remove a item
	sut.remove(objectID: item.objectID)
	sut.save()
	
	//Assert number of item - 1
	XCTAssertEqual(numberOfItemsInPersistentStore(), numberOfItems-1)
	
}

//Convenient method for getting the number of data in store now
func numberOfItemsInPersistentStore() -> Int {
	let request: NSFetchRequest<NSFetchRequestResult> = NSFetchRequest(entityName: "ToDoItem")
	let results = try! mockPersistantContainer.viewContext.fetch(request)
	return results.count
}

在testfetchalltodo()中，因為我們已經知道stub總共的數量是5個，所以我們直接使用5來當做我們的assertion。

另外，在testremovetodo()裡面，我們做了一些妥協，因為我們的寫入是寫到backgroundContext，但我們的numberOfItemsInPersistentStore()卻是讀viewContext的資料，所以我們需要先執行save()這個side effect，才能assert正確的數量。未來可以透過mock一個完全客制化的NSPersistentContainer，產生指定的backgroundContext來解決這個問題，不過這邊讓我們先專注在fake跟stub就好。

上面這些東西的操作，全部都是在記憶體中操作，但對我們的SUT來說，因為接口一模一樣，都是NSPersistentContainer，所以互動的方式跟production是一模一樣的。

Expectations to Notification

到此，我們還有一個case還沒有寫到：

1. 呼叫save()，要能夠對資料庫執行Save

這個case的目的，是要確保我們的ToDoStorageManager.save()真的有呼叫到NSManagedObjectContext.save()，讓資料真的有寫入persistent store。依照我們平常mock的作法，我們應該要建立一個NSManagedObjectContextProtocol，並且產生一個mock來conform這個protocol，然後利用mock來得知NSManagedObjectContext.save()是不是真的有被呼叫(再次宣傳一下，可以參考拙作(https://www.codementor.io/koromiko/unit-test-for-networking-ahdpdqr5k))。但問題來了，我們的dependency是NSPersistentContainer，所有的context都被封裝在這個container之中，並且目前也沒有方法可以在container中植入自己的context，所以我們必須要找別的方法來做這個behavior test。

如果不能透過mock來了解save()的運作，我們還有另外一個妥協的方法，在Core Data，只要context有變動，都會發出對應的notification，我們只要聽這些notification，就可以知道我們的SUT是不是真的有對context下save()。在這邊我們會專注在NSManagedObjectContextDidSave這個notification，這個notification會在資料被存回persistent store後觸發，只要有收到這個notification，就表示NSManagedContext.save()是有被觸發的。

所以我們在setUp()裡面，註冊這個notification：

NotificationCenter.default.addObserver(self, selector: #selector(contextSaved(notification:)), name: NSNotification.Name.NSManagedObjectContextDidSave , object: nil)

然後設定好這個notification的handler：

func contextSaved( notification: Notification ) {
}

接著我們來看一下我們save()的測試code：

func test_save() {
			
	//Give a todo item
	let name = "Todo1"
	let finished = false
	
	_ = expectationForSaveNotification()
	
	_ = sut.insertTodoItem(name: name, finished: finished)
	
	//When save
	sut.save()
	
	//Assert save is called via notification (wait)
	waitForExpectations(timeout: 1, handler: nil)

}

在這一個case之中，我們做的事情是：新增一個todo list，並且等待NSManagedObjectContextDidSave(也就是expectationForSaveNotification)，在一秒內收到這個notification(也就是waitForExpectations)，這個test case才算有過。因為notification是一個非同步的行為，所以我們需要利用XCTestExpectation，來做非同步的測試。讓我們先來看一下expectationForSaveNotification()的實作：

func expectationForSaveNotification() -> XCTestExpectation {
	let expect = expectation(description: "Context Saved")
	//After Do something async {
		expect.fulfill()
		// }
	return expect
}

expectation(description: "Context Saved”)是一個在XCTestCase已經定義的method，目地是要設定一個XCTestExpectation物件，並且將這個expectation加入清單，接著只要在你的test case裡面加上waitForExpectations(timeout: TimeInterval, handler: XCTest.XCWaitCompletionHandler? = nil)，那個test case就會一直等待，等到expect.fulfill()被觸發之後，才會通過測試，如果在timeout設定的時間前，都沒收到任何fulfill()的呼叫，這個case就會被判定失敗。

接著，因為我們等待的是一個notification，所以上面的After Do something async，會這樣實作：

//MARK: Convinient function for notification
var saveNotificationCompleteHandler: ((Notification)->())?

func waitForSavedNotification(completeHandler: @escaping ((Notification)->()) ) {
	saveNotificationCompleteHandler = completeHandler
}

func contextSaved( notification: Notification ) {
	saveNotificationCompleteHandler?(notification)
}

在waitForSavedNotification中，我們先把complete handler存下來，等到在contextSaved(Notification:)中收到notification之後，再呼叫這個handler，達到async的效果，一旦這個complete handler被呼叫了，就會觸發expect.fulfill()，而waitForExpectations就會被滿足，測試case也就順利通過了！

Recap

在這篇文章中，我們學習到了：

1. 怎樣用NSPersistentContainer設定Core Data stack
2. 怎樣設定Fake及Stub for Core Data
3. 怎麼在XCTestCase中做非同步的測試

完整的程式可以在我的Github(https://github.com/koromiko/Tutorial/tree/master/PersistentTodoList)上面找到。

Summary

對Core Data來說，其實有許許多多種測試的方法，最常見的還是mock NSManagedObjectContext，也有許多文章已經有做過探討：

How to Create Mocks and Stubs in Swift - Andrew Bancroft(https://www.andrewcbancroft.com/2014/07/15/how-to-create-mocks-and-stubs-in-swift/)

Real-World Testing with XCTest · objc.io(https://www.objc.io/issues/15-testing/xctest/#core-data)

不過為了要符合iOS 10以後新的Core Data stack用法，小弟試著做了一些研究，試著在NSPersistentContainer的狀況下做測試，雖然很多地方需要稍微繞路一下，但整體來說該測試的地方都還是可以完整地測試，並且也相當獨立於真實環境之外，希望這些方法能夠帶來一點幫助。

最後，在寫這篇文章的同時，已經越來越多人投入Realm的懷抱了，找了一個大大詢問Core Data的細節，想不到他直接跟我說他只有用Realm從來沒用過Core Data，這就是時代的眼淚嗎QQ

References

Core Data Programming Guide: Persistent Store Types and Behaviors(https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CoreData/PersistentStoreFeatures.html)

iOS 10 Core Data In Memory Store for Unit Tests - Stack Overflow(https://stackoverflow.com/questions/39004864/ios-10-core-data-in-memory-store-for-unit-tests)

Data Models and Model Objects · objc.io(https://www.objc.io/issues/4-core-data/core-data-models-and-model-objects/#data-model)

Real-World Testing with XCTest · objc.io(https://www.objc.io/issues/15-testing/xctest/#why-we-are-testing)

Easier Core Data Setup with Persistent Containers(https://useyourloaf.com/blog/easier-core-data-setup-with-persistent-containers/)

TestDouble(https://martinfowler.com/bliki/TestDouble.html)

好不容易來到了續作的第三集，就這樣以近乎休刊般的速度，也寫了三篇長篇了。雖然對很多高手前輩來說，這些都是非常基礎的東西，但小蛇在跌跌撞撞了許久(還在跌)後，覺得有些東西還是自己寫下來，可以再次釐清自己的觀念，也偷偷希望能夠獲得高手指點或是加入討論，這就是邊緣人參與社會的方式阿(跟本就只是偷懶吧)。

話不多說(已經說很多了，想看電影心得可以直接跳到最後)，就讓我們進入今天的主題。

這篇我們要來談談開發上更貼近實務的部份：如何設計一個好的軟體架構，以及如何測試它。在iOS開發過程中，如果是比較大型的app，通常複雜度都非常高，而且手機開發所需要架構的東西，必須要融合前後端的知識，從跟使用者第一線接觸的UI，到手機底層的資料庫，都必須透過你的code來連接跟協調。這個架構好不好讀、好不好維護、好不好測試，就會是整個開發的重點了，如果這個架構不是很好，接手的人或合作的人無法快速理解，就連你自己有時候都看不太懂，那未來某一天你一定掉進你自己挖出來的大坑裡(對，小蛇我還在我挖的坑裡)。

講架構或許有點抽象，要把既有的架構法則套到自己的程式中也不是一天兩天的事情，但有個好方法或許可以試一下，從現在開始，你可以試著培養自己的測試腦。甚麼是測試腦？就是接下來我所要做的事情，我所要做的改變，都是

為了要讓測試更容易。

你很難想像怎樣的程式是乾淨的程式，畢竟軟體開發的法則很多，光是要不要寫註解就有非常多說法了，對於像小蛇一樣資歷不深的人來說，跟本背不起來更不用說活用了。但專注在讓code容易寫測試，就沒有那麼難了，因為你一開始要寫測試，就會發現

ㄊㄇㄉ我的程式跟本無法寫測試阿阿阿！

從這邊開始，你就會去研究怎樣decoupling，研究design pattern，研究各種既有的架構，而不是因為教主說它好用就用，這就是好的開始。所以來跟我說一次，感恩ㄙ...不對，是「我要讓測試更容易」！

關於這個架構文，我會把故事拆分成兩篇文章，第一篇會講到一般的Apple MVC架構既有的問題，還有我們要怎樣改善它。第二篇則是會講到如何針對MVVM的架構來撰寫unit test。

TL;DR

在這篇文章裡，你可以了解到：

• Apple MVC架構所帶來的問題
• 利用MVVM來設計更乾淨的架構
• 一個簡單的MVVM App範例

同時，你在這篇文章裡將不會看到：

• MVC、MVVM、VIPER的比較
• MVVM洗腦大會
• 萬能的軟體架構

以一個軟體開發者來說，除非你停止開發(或停止呼吸)了，不然軟體架構永遠都不會有最好的、最完美的時候，在開發的過程中，你總是可以找到更好的模式，總是會學到新的方法，這些東西都可以不斷讓你的架構更乾淨更好懂，所以在這篇文章裡，重點會放在為甚麼要使用MVVM，它解決了怎樣的問題，相信這些背後的脈絡，也同時可以套用在其它不同的架構上，MVVM只是你跟真實世界接觸的載體而已(硬要套點電影式的假哲學)。

Apple MVC

Apple所提倡的MVC(Model-View-Controller)，是在iOS開發過程中，第一個會遇到的架構。在原本的MVC之中，Model代表資料，View代表視圖，Controller則是負責商業邏輯。這三者的互動方式如下圖：

Controller同時擁有View跟Model，並且做為統整兩邊的橋樑的角色。但故事來到了iOS開發，因為View角色特殊的關係，原本的MVC變成了Model-ViewController+View：

ViewController包含了View，並且加入了一些View的life cycle的邏輯。因為UIViewController地位特別的關係，View跟Controller的code都會出現在UIViewController裡面，這樣會造成UIViewController變得相當肥大，也就是大家常說的Massive View Controller。並且這個UIViewController其實很不好寫Unit Test，因為你的Controller邏輯跟View綁得太深。你如果想要測某個Controller的功能，就必須要mock某個view以及它的life cycle，這樣是很不符合經濟效益的。

針對Apple MVC的問題，網路上已經有非常多的討論跟解法，不管是那一種解決辦法，主要的施力點，都是把過多的邏輯，從UIViewController裡面切分出來，並且設計一個乾淨的架構，讓所有的物件能夠盡量遵循single responsibility原則，不要有分工不明的問題。目前常見的替代架構有MVVM、VIPER兩種，都是解決Massive View Controller的好方法，也都有各自的優缺點。因為MVVM比較好上手，也比較能夠拿來解釋切分權責的步驟，所以接下來我們會以MVVM為主，介紹MVVM以及怎樣拿MVVM來解決MVC的問題。

MVVM - Model - View - ViewModel

MVVM的概念最早應該是在2005年由Microsoft的John Gossman提出來的，它的概念是，整個模組會拆分成三個部份，View、ViewModel、Model，其中View的角色就是單純的視覺元件，像是按鈕、文字標籤等等，在View裡面不會有邏輯、狀態等等，單純就是個呈現資料的元件。而要讓View呈現資料，最直覺的方式，就是把View跟Model做綁定，讓View的元件跟著Model一起做變化。但這樣會有個問題，就是通常Model來的資料，並不是簡單就能轉換成View的樣式的，這時候就需要有個物件，介在View跟Model的中間，這個物件會掌管這些跟View高度相關的邏輯的操作，像是轉換Date物件變成人看得懂的文字格式等，稱之為ViewModel。上面的概念可以畫成這樣的資料流：

流程上，ViewModel會從Model取到資料，並且把資料整理好成為方便顯示的樣子，而View一看到ViewModel的資料有更新，就會跟著一起更新，這就是一個最單純的MVVM資料流。

在iOS開發上，依照上述MVVM的定義，UIViewController變成一個單純的View，而我們會另外產生一個ViewModel來負責presentational logic跟部份的controller logic。所以在你的ViewController裡面，就只會有：

1. View logic，所有跟呈現有關的Code
2. 綁定ViewModel

而在ViewModel裡面，則是負責兩個部份：

1. Controller logic，如pagination, error handling,… etc
2. Presentation logic，提供接口讓View綁定(binding)

開發上，一旦View綁定好ViewModel的資料，在撰寫商業邏輯的時候，就可以不用管包括動畫、轉場、main thread等等跟View相關的問題，因為分工明確所以就不會有寫起來綁手綁腳的感覺。更棒的是，並且因為ViewModel是一個單純的、沒有相依於View的物件，所以要做測試簡單多了！

在文末我們會討論這個其實也身兼多職的ViewModel到底有甚麼問題，就讓我們繼續看下去～

A simple gallery app - MVC

接下來，我們要用一個簡單的例子，來讓大家了解怎麼從MVC轉換到MVVM。

這是一個簡單的App，具有下面兩個功能：

1. 會從500px API抓取熱門相片，並且把相片排成列表show出來，每張相片都會顯示標題、描述、跟拍攝日期。
2. 如果使用者點選了非賣品，app就不會讓使用者進到下一頁，並且跳出錯誤訊息。

請看以下示意圖：

在這個app裡，我們會有一個Model，叫Photo，代表的就是一張照片，這個Model會跟JSON上拿到的資料格式一樣，如下：

https://gist.github.com/koromiko/14daab5f0e8bad28447dffcb4486c7f2
而我們透過一個APIService物件，上網去抓資料，並且把資料轉成Photo物件供ViewController使用，並且由一個activity indicator來顯示讀取中的資訊，這個事件發生在ViewDidLoad裡面：

https://gist.github.com/koromiko/4f5d9eb32501ee0bf450548ce95d28e6
而這個tableView的data source，也會寫在這個VIewController裡面，如下：

https://gist.github.com/koromiko/f905fd49023907440d2da12753063521
這個tableView的數量就等同於抓下來的Photo數量，並且在reuse cell時，取對應的photo物件，打包成對應的格式，設定到cell上面。在這裡，因為Date物件無法直接顯示在View上面，需要變成”yyyy-MM-dd”這樣的格式，所以我們要在指定資料到UILabel上之前做轉換，把Date轉成字串讓label可以正確顯示。

而跟使用者互動的delegate部份，則是這樣：

https://gist.github.com/koromiko/7cd42d963f3d02bf88faac630a67705b
在func tableView(_ tableView: UITableView, willSelectRowAt indexPath: IndexPath) -> IndexPath?裡面，我們會先去判斷使用者點選的照片，如果點選的照片是for sale的，就記錄使用者點選的indexPath供segue使用。如果點選的不是for sale，就跳出一個alert，說這是非賣品，並且回傳nil，讓segue不要發生。

以上就是一個最簡單的app，詳細的原始碼可以參照這裡(tag::”MVC”)。

這是基本的Apple MVC架構，也是各種教學中常見的範例，打字快一點的人應該不用幾分鐘就可以刻出這樣的東西來。但這東西有甚麼問題？在這個MVC裡面，同時也有像是activity indicator、tableview出現或消失等等的邏輯(Presnetation logic)，也有上網取資料的邏輯(Controller logic)，加上View跟它們的life cycle整個被綁在UIViewController裡面，所以這個ViewController的角色變得有點混亂。更麻煩的是，這個ViewController是很難被測試的！除非Mock整張tableView與它的cell，不然我們沒辦法知道date是不是真的正確地被轉成該有的樣子，我們也需要mock activity indicator，才能夠知道loading的狀態是不是有正確地對應，這個測試寫起來會非常可怕。

為了讓測試變的更容易，讓我們動手來改變這一切。

Let’s do MVVM

為了要解決上面這些問題，我們的首要之務就是要清理ViewController，讓部份的邏輯獨立出來，成為一個有主權、有領土、能自決的物件！(是不是很值得支持) 回顧剛剛MVVM的定義，我們目前的任務就是：

1. 把View跟ViewModel做綁定
2. 把controller logic跟presentation logic從ViewController移到ViewModel

先看綁定的部份，在頁面上，我們的View上有幾個主要元件：

1. activity Indicator (loading/finish)
2. tableView (show/hide)
3. cells (title, description, created date)

如果我們把這些元件的資料跟狀態整理出來，抽象化成為一些ViewModel的接口，就會變成像下圖這樣：

所有的View的狀態，都有他們對應的ViewModel properties，並且每個cell也都有相對應的ViewModels，這樣就能夠確保View的長相就是我們在ViewModel上面看到的一樣。

那實作上我們要怎麼做綁定呢？

Implement the Binding with Closure

在Swift裡，要做到資料綁定，有幾種方法：

1. 用ObjC的KVO pattern
2. 使用FRP套件如RxSwift或ReactiveCocoa提供的binding功能
3. 自己實作

使用ObjC的KVO(Key-Value Observer)是個不錯的方法，但是因為KVO本身在ObjC裡特別的設計，所有更新數值都是透過一個delegate function來達成，所以使用KVO在ViewController裡面會變得有點複雜，這樣就失去我們想要簡化的意義了。使用FRP(Functional Reactive Programming)提供的binding是最方便的，一旦引入了signal跟event的概念後，View跟ViewModel之間的互動就有統一且直觀的作法，不過因為FRP是一個不小的概念，為了避免失焦所以在這邊我們也不使用。自己實作綁定的話，有不少方法，像是這篇利用decorator pattern來做到不同類型的物件綁定，很值得深入研究。

在這篇文章，我們選擇一個更單純的做法：利用Closure，讓ViewController去等待ViewModel的改變，來觸發View的更新，達到綁定的效果。

具體來說，一個在ViewModel裡面，即將跟View綁定的property，會長這個樣子：

https://gist.github.com/koromiko/9de5d10f919b572f5cc201fe5301826c
在View初始化ViewModel時，會順便設定好viewModel.triggerVIewUpdate：

https://gist.github.com/koromiko/d4704a89200444575624ab0dc5d2ff46
所以每當ViewModel裡面的prop更新時，都會觸發這個closure，進而讓View做某些更新，這種綁定很好理解並且瑣碎的code也不多，也可以很靈活的運用。

Interfaces for binding - ViewModel

現在我們可以來寫code了！我們先設計出簡單的PhotoListViewModel，具有接口如下：

https://gist.github.com/koromiko/97e95db0a30d9b6100a4b96f1a2d21f7
每個cell的ViewModel，都被存在cellViewModels裡面，都可以透過getCellViewModel來取得，cell的數量則是透過numberOfCells來取得，只要cellViewModels這個property一更新，tableView就會跟著重整。而每一個cellViewModel會長得像下面這樣：

https://gist.github.com/koromiko/0ee1b101c605b0b83a0396549c14f8df
這個PhotoListCellViewModel代表每一個即將出現在cell上面的資訊，所以cell只要照著上面的資料呈現視圖就好，不用做任何轉換。

Bind View with ViewModel

有了上面這些接口，接著我們就要來撰寫ViewController的部份。首先，在ViewDidLoad先指定好ViewModel的closure：

https://gist.github.com/koromiko/c4b463e33b58438214af090b72d1a22d
針對tableView的datasource，則改成從PhotoListViewModel拿到PhotoListCellViewModel，在利用cellViewModel來指示cell要怎樣呈現：

https://gist.github.com/koromiko/f25e866d209c7048544c4d64fe5251fb
這樣資料流就變成了，ViewModel一旦整理好資料，View就會去跟ViewModel拿整理好的資料，更新自己並且顯現出來。完整的資料流會長得像下圖一樣：

User interaction - View

如果使用者有互動的時候呢？我們在ViewModel裡面，提供了這樣的接口：

https://gist.github.com/koromiko/9734097d9968a789b87aa9fcf7c27fb1

這個接口讓ViewModel能夠接收使用者的行為，並且針對這樣的行為做出對應的動作。對ViewController來說，table view delegate就可以變得更簡單了：

https://gist.github.com/koromiko/df132d8c3b00df3e7a97ca26f5d498a7
View一接收到使用者的動作，就馬上把它傳給ViewModel，並且由ViewModel透過isAllowSegue來決定，到底該不該啟動這個segue，View就是一個能夠體察上意的，恩，好官員XD

Implementation of PhotoListViewModel

那ViewModel裡面是長怎樣呢？在這個應用中，ViewModel負責上網抓資料，並且把資料轉換成供呈現的PhotoListCellViewModel，所以我們使用了一個array來裝這這些cellViewModels：

https://gist.github.com/koromiko/c9dd601bfa9f98be35aaee7f1f57b78a
在ViewModel的初始化階段，我們做兩件事情：

1. 注入dependency - APIService
2. 開始抓取資料

https://gist.github.com/koromiko/85819122f0a76bd2d76115880e6bea24
在這段code裡面，我們會跟APIService要資料，在要資料之前先把isLoading設定成true，因為isLoading有跟View做綁定，所以View會針對這個事件轉換成讀取中的樣式。在資料全部都取下來之後，在processFetchedPhoto(photo:)裡面，把資料轉化成適合顯示的樣子(cellViewModels)，並且把讀取中的狀態設定成false，這時候View會因為isLoading變成false，activity indicator就會停止轉動，也會因為cellViewModel的更新，重整table view並且把新的資料show出來。

下面是processFetchedPhoto的實作：

https://gist.github.com/koromiko/3078690354fb646d9eeae64c670503f5
它把收到的photo，透過createCellViewModel( photo: Photo)轉成了一個一個的CellViewModel，這些CellViewModel，在資料上長得跟Cell是一樣的，未來Cell在呈現時，就會照著CellViewModel的資訊，一五一十地反應出來。

Yay！我們終於完成了所有的綁定跟改寫！

以上的程式，都可以在我的Github裡面找到。

Github - MVVMPlayground

其中MVC版的App可以翻到”MVC”這個tag，而最新的commit就是MVVM加上測試的版本。

“MVVM is Not Very Good”

就像上面提到的，永遠沒有最好的架構，相信你看完這篇文章之後，也大概猜得到MVVM有甚麼問題了，網路上也已經有蠻多關於MVVM的缺點的討論，如：

MVVM is Not Very Good - Soroush Khanlou

The Problems with MVVM on iOS - Daniel Hall

其中，第一篇可以說是砲火猛烈，並且引起了不少討論，兩篇作者共同的論點是MVVM其實跟MVC跟本差不多，只是把一推code從viewController移到另外一個地方，它們還是一堆code。這個說法基本上忽略了很重要的一點：透過MVVM，我們離可測試的程式碼又躍進了一大步了！對ViewModel來說，它完全沒有View的包袱，但又可以利用簡單的assert來測試呈現效果。MVVM跟原本的MVC乍看之下很像，但就測試跟權責分離來說，還是很不一樣的。

對於小弟來說，MVVM最大的缺點，就是controller跟presentation layer的定義模糊，大多數(包含我自己)的人，都把controller的工作，跟presenter一起放在view model裡面了，也就是說view model同時又負責協調網路層、資料庫層(controller)，同時也處理轉換資料成為可綁定的對象(presenter)，以我們的相片app來說，PhotoListViewModel做了相當多的controller任務，但PhotoListCellViewModel就是個單純的presenter。

另外，MVVM還有一個非常致命的缺點，就是缺少router跟builder這兩個角色，router負責頁面切換的邏輯，而builder負責初始化這一切。這兩個角色，在大多的MVVM應用中，都被寫到viewController裡面了。

以上這兩點，當然也已經有人提出並且有對應的解法了，其中一種解法是VIPER架構，另外一個則是MVVM+FlowController(Improve your iOS Architecture with FlowControllers)，這兩個都是非常棒的設計，其中MVVM+FlowController的概念我很喜歡，未來會再針對router+builder的議題研究一下再做分享。

架構只是輔助

在開發世界中，沒有最好的架構，與其爭論那一個比較好或者誰用的是正統誰用的不是，不如先了解一下，這些架構出現的前因後果，還有他們身上所背負的使命，如果能夠一直保持著「我要讓測試變得好寫」這樣的心情去看待這些架構，就會發現他們已經很有效地完成了他們的任務了。我選用MVVM來架構我的程式的理由非常簡單，就是它比較好理解，也比較容易上手。可以延伸閱讀Soroush Khanlou的另外一篇文章8 Patterns to Help You Destroy Massive View Controller，裡面提到了很多架構的基本法則，你會發現大家努力的方向都是類似的，都盡量希望物件能夠有單一的責任，都希望利用composite pattern來decoupling。而現階段MVVM的設計也是朝著這樣的方前在前進著。

下一篇我們就要來進入幫MVVM寫測試的世界囉！將以休刊般的速度出刊，敬請期待！

文章參考非常多相關的資料，但還是很怕有觀念上的謬誤，如果有誤歡迎大力指正，也歡迎在底下加入討論。

歡迎來到真實世界目前總共有三集，歡迎一併觀賞！

歡迎來到真實世界 – Unit Test for Networking

歡迎來到真實世界 – Unit Test for Core Data

歡迎來到真實世界 – 原來是那個傳說中的MVVM阿

參考資料

Introduction to Model/View/ViewModel pattern for building WPF apps - John Gossman

Introduction to MVVM - objc

iOS Architecture Patterns - Bohdan Orlov

Model-View-ViewModel with swift - SwiftyJimmy

Swift Tutorial: An Introduction to the MVVM Design Pattern -  DINO BARTOŠAK

MVVM - Writing a Testable Presentation Layer with MVVM - Brent Edwards

Bindings, Generics, Swift and MVVM - Srdan Rasic

恭喜你很有耐心地看到了這裡(直接按End好像也會到這邊？)，延續之前的好傳統(?)，分享一下個人近期喜愛的好電影！

最近看了一部電影，American History X，是1998年的電影，主角是後來演了轟動世界的Fighting Club的Edward Norton。故事是在描述一個具有種族主義的天才主角，在入獄前後，跟家人還有社區的互動跟心路歷程。導演巧妙地利用一長一短的雙時間軸，深刻地描繪了哥哥(3到5年)跟弟弟(一個晚上)的互動與成長。這部電影直接把美國的種族主義問題，毫不掩飾地搬上檯面，逼觀眾加入這個戰局，好好思考這樣反智的行為是怎樣產生的，還有他們的歷史脈絡。喜歡社會思考的電影人千萬不要錯過，尤其這樣赤裸地講出種族主義問題的電影真的不多，加上Edward Norton非常完美的演出，真的是一部經典好電影。

在上班通勤的時候，最常做的事情就是打電動了。實在有點難在公車上面看書或做認真的事，請問除了高中生之外誰會在公車上認真做事的？那個奈米短的專注時間要思考任何事情都有困難。但是打Clash Royal就不一樣了，那是一款會讓你在毫秒之內進入精神時光屋的遊戲，只要開戰之後你就會到瞬間另外一個世界，直到戰鬥結束前你都不會回到現實，就算坐過站也是一樣。雖然一場只有兩分鐘，但對你來說每一場都像列寧格勒圍城戰一樣，都是漫長的持久戰，也像台灣的政治一樣，都是平行的時空。

如果想了完整的平行時空，就不能不提駭客任務(the Matrix)，這部電影一直都是心目中最經典的電影之一，除了子彈時間這個讓人萬分驚豔的嘗試之外，許許多多的哲學問題在這部電影裡面都有簡單的著墨，是一部既大眾化又有點燒腦的好電影，下一部能夠相題並論的Cyberpunk商業電影，大概就只剩Inception了。

所以，對，在重要但無用的前情提要之後，就來進入到我們今天的主題了：歡迎來到真實世界！這將會是一連串的分享文，想要分享的是一個很多人(包括小弟我)都不願意提到的”那個議題”：Unit Test in iOS。嗯，很輕易就講出來了。

Welcome to the real world

一般來說，在iOS開發上，寫測試這件事不算是非常的普遍，所以相關的資源可能不像其它語言這麼多，小弟在還在玩沙的時候，就為了寫測試原地打轉了非常久，一直想要了解某些功能要怎樣測試、要怎樣設定情境，但又有點不知道怎樣下手。所以這一系列的文章會試著把小弟看過的資源跟理解的內容、還有實務上的運作整理出來，希望可以拋磚引玉，讓大家都能夠踏入這個殿堂之中。

因為是分享文，所以接下來並不會巨細瀰遺地把所有細節講出來，但我沒提到的都會是網路上已經非常常見、已經有教學的，所以請大家不用擔心，反之這些文章會以整個測試的脈絡為主，在觀念的釐清會多於語法的描述。

第一篇要來談的就是，關於寫測試，讓人最為困擾、也是整個測試101中一個非常重要的觀念：Depedency Injection。

在寫單元測試的時候，如果遇到你要測試的物件，是跟真實世界有介接的，像是network、database等等，就會變的比較不容易測試，因為你總不會希望每次跑測試，都需要連上網路，都需要接上資料庫並且寫入真實資料吧。寫測試有個大原則：不要仰賴任何真實環境，如果我們的測試需要仰賴真實環境，那我們就會遇到許多問題：

1. 速度很慢
2. 測試資料會汙染到真實環境
3. 一但換個開發環境(沒網路等等)就無法開發了

所以最好的做法，是我們需要有一個虛擬的環境，讓我們的測試都跑在這個虛擬的環境之中，所有的請求都是直接接到這個假環境，而不是真實世界。這有點像在the Matrix裡面，我們只要抽換掉腦袋後面的插頭，就能夠把環境注入到我們運作中的腦袋之中，接下來我們做的事情，都跟另外一個世界沒有關係，在這個環境之中，因為它的一切物理特性都跟真實世界一樣，學到的東西也會是一樣的，所以我們可以在假環境中訓練，回到真實世界打鬥，也就是說，我們可以在測試環境中把code寫好，丟到真實世界中也能夠運作正常。

TL;DR

以下內容會提到：

1. 怎麼利用Dependency Injection設計一個更好測試的物件
2. 怎麼利用Protocol來製作mock物件
3. 怎麼測試資料正確性跟行為正確性

Dependency Injection (DI)

Ok，回到我們即將要撰寫的程式上，我們現在要實做一個，能夠發出http get請求的HttpClient類別，這樣的類別，它可能需要滿足以下條件：

1. 發出的request的URL要跟我們指定的一樣
2. 要真的有發出request

好的，我們先咻咻咻地寫了一個HttpClient：

class HttpClient {

    typealias completeClosure = ( _ data: Data?, _ error: Error?)->Void

    func get( url: URL, callback: @escaping completeClosure ) {
        let request = NSMutableURLRequest(url: url)
        request.httpMethod = "GET"
        let task = URLSession.shared.dataTask(with: request) { (data, response, error) in
            callback(data, error)
        }
        task.resume()
        }

}

看起來這個程式，可以發出get request，並且把資料透過callback這個closure回傳，所以它可以這樣使用：

HttpClient().get(url: url) { (success, response) in
    // Return data
}

問題來了，我們要怎樣測試它呢？我每次只要呼叫get(URL, completeClosure)這個method，它都會直接毫無懸念地連上網，並且義無反顧地上我指定的server拿資料，這樣不行！所以我們仔細地看一下這支程式，你會發現，直接連上網路的關鍵，在於那個萬惡的URLSession.shared這個singleton，只要它一直存在在這個程式裡面，我就每次都需要連上網路，並且抓資料下來，所以我們必需要來動手改造它，URLSession就是一種”環境”，我們要讓它是可以替換，可以被”注入”的。所以我們又咻咻咻地改寫了這個class：

class HttpClient {

    typealias completeClosure = ( _ data: Data?, _ error: Error?)->Void

    private let session: URLSession

    init(session: URLSessionProtocol) {
        self.session = session
    }
    
    func get( url: URL, callback: @escaping completeClosure ) {
        let request = NSMutableURLRequest(url: url)
        request.httpMethod = "GET"
        let task = session.dataTask(with: request) { (data, response, error) in
            callback(data, error)
        }
        task.resume()
    }

}

我們把

let task = URLSession.shared.dataTask()

改成了

let task = session.dataTask()

並且新增了一個變數session，並且新增了對應的init。從此之後，我們在創建HttpClient時，就需要指定這個session，也就是說，我們在創建HttpClient時，就需要把對應的環境”注入”這個物件之中，如果我們放了個假session，HttpClient還是會在這個假session之中打打殺殺，但就完全不會碰觸到真實世界的URLSession.shared了。所以我們的應用就變成了：

HttpClient(session: SomeURLSession() ).get(url: url) { (success, response) in
    // Return data
}

未來在使用HttpClient時，都需要注意這邊有個URLSession的相依性，需要依照我們的使用情境來注入不一樣的session。

當我們把環境抽離之後，要寫測試就變得很容易了，依照我們的需求，我們需要寫兩隻簡單的單元測試，所以我們再度咻咻咻地寫出了以下的測試架構：

class HttpClientTests: XCTestCase {
    var httpClient: HttpClient!
    let session = MockURLSession()

    override func setUp() {
        super.setUp()
        httpClient = HttpClient(session: session)
    }
    override func tearDown() {
        super.tearDown()
    }
}

這邊我們設定了一個session，我們希望知道我們的物件(HttpClient)跟這個假環境(session)的互動狀況，這個假環境通常被稱做Mock，目地就是要拿來了解我們製作中的物件，是不是有乖乖地執行某些method，或是有沒有做某些特定的行為。接下來，可以在setUp裡面看到，我們創了一個HttpClient，並且把這個MockSession注入了這個HttpClient之中，所以現在，這個HttpClient，已經離開母體，到了虛擬的世界了！接下來我們就可以放心地實作我們的規格，而不用擔心速度跟汙染資料的問題了。

Test data

好的，現在我們來看看我們的第一個目標：

1. 發出的request的URL要跟我們指定的一樣

身為一個稱職的HttpClient，就需要能夠正確地發出request，不能亂動URL，所以我們咻咻咻地寫了一個簡單的get request到我們的測試之中：

func test_get_request_with_URL() {

    guard let url = URL(string: "https://mockurl") else {
        fatalError("URL can't be empty")
    }

    httpClient.get(url: url) { (success, response) in
        // Return data
    }

}

接續剛剛提到的，想知道我們的實作是不是有正確地做某些動作，我們需要對我們的mock物件動手腳，就上面這兩個case來說，我們需要的是：

mock物件要有個接口讓我們知道URLSession最後發出去的URL是甚麼

所以接下來，我們要進入我們的重頭戲：怎樣設計這個mock object。我們要做一個長得很像URLSession，也就是跟URLSession有一樣的method的物件，並且在我們mock的URLSession裡面，埋一些能夠記錄的變數，好讓我們知道我們的HttpClient是不是真的有call那些method。

一般我們要發出一個requesst，通常會這樣寫：

let task = session.dataTask(with: request) { (data, response, error) in
    callback(data, error)
}
task.resume()

URLSession的dataTask()就是我們想mock的目標，所以我們先寫一個mock架構：

class MockURLSession {

    private (set) var lastURL: URL?

    func dataTask(with request: NSURLRequest, completionHandler: @escaping DataTaskResult) -> URLSessionDataTask {

        lastURL = request.url

        completionHandler(nextData, successHttpURLResponse(request: request), nextError)        

        return // dataTask
    }

}

上面這就是基本的Mock架構，這是一個互動跟URLSession一樣的mock，能夠回傳dataTask，並且呼叫completionHandler作為成功的回應。在return這邊我們先留空白，因為dataTask跟Session有相依，這是另外一個我們需要mock的東西。回到上面的code，有一個接口跟URLSession一模一樣的datTask method，來跟我們的HttpClient做互動。我們的記錄，就埋在lastURL這個property裡面，所以一旦HttpClient的get()準備發出request，它就會呼叫這個datTask()，並且把最後發出去的URL存到lastURL這個變數裡面。

另一方面，我們的test case會寫成這樣：

func test_get_request_with_URL() {

    guard let url = URL(string: "https://mockurl") else {
        fatalError("URL can't be empty")
    }

    httpClient.get(url: url) { (success, response) in
        // Return data
    }

    XCTAssert(session.lastURL == url)
}

只要assert lastURL是不是有符合我們設定的url，就可以知道我們發出的get()是不是有正確地設定URL了。

在上面的mock實作中，有一個地方我們並沒有寫完，就是在return // dataTask 這邊，這個地方理論上要回傳一個URLSessionDataTask物件，但是這個物件需要從某個URLSession instance創建出來，因為我們的mock URLSession沒有這個功能，所以我們需要再mock一個URLSessionDataTask。

class MockURLSessionDataTask {   
    func resume() { }
}

這個mock，就只有一個功能，就是仿製dataTask的resume()，這樣在進到我們這個假環境之後，就會呼叫這個mock的resume，之後就可以在這邊做記錄，記錄resume是不是有正確地被呼叫，後面會再提到。

到目前為止，這些code都是compile不過的。人生就是這樣，你努力了一大圈，卻發現最後還是compile不過。但，先別對人生失望！這跟當魯蛇不一樣，compile失敗，只是一時的，是可以解決的(有沒有很正向思考！)。到目前為止，compile不過，都是因為我們雖然mock了這些東西，但對compiler來說，這些東西介面上還不能直接這樣用，我們需要利用protocol來讓compiler把真實環境跟測試環境都視為一樣的。回頭來看一下我們的HttpClient：

 private let session: URLSession

這個private property我們設定成URLSession，但是我們製作的mock卻是MockURLSession，兩個類別不一樣，compiler會在呼叫的時候報錯：

class HttpClientTests: XCTestCase {
    var httpClient: HttpClient!
    let session = MockURLSession()

    override func setUp() {
        super.setUp()
        httpClient = HttpClient(session: session) // 這邊會炸
    }
    override func tearDown() {
        super.tearDown()
    }
}

這時候，我們有幾種作法可以騙過compiler，一種是透過subclass，讓MockURLSession也是URLSession的subclass，在這邊我們不使用subclass，因為我們要mock的目標不是我們自己的物件(URLSession)，如果用subclass，有可能會誤觸到我們測試定義以外的範圍。

另外一種方法，是透過protocol，讓URLSession跟MockURLSession都遵詢某種protocol，再修改

 private let session: URLSession

成為

 private let session: URLSessionProtocol

接下來只要讓URLSession跟MockURLSession都符合這個我們定義的URLSessionProtocol，就可以順利地compile了。因為HttpClient的dependency從原本的URLSession變成URLSessionProtocol，所以之後我們的mock不管怎樣修改，只要conform這個protocol，你就可以成為這個HttpClient的dependency，也就是說，只要行為模式一樣，就可以自由替換這個HttpClient執行的環境。

這個URLSessionProtocol，我們會這樣設計：

protocol URLSessionProtocol {
    typealias DataTaskResult = (Data?, URLResponse?, Error?) -> Void

    func dataTask(with request: NSURLRequest, completionHandler: @escaping DataTaskResult) -> URLSessionDataTaskProtocol
}

為了方便閱讀，我習慣幫closure加上typeaslias。

這邊我們只定義了一個需要conform的method：dataTask(NSURLRequest, DataTaskResult)，因為目前我們的測試就只有需要這個。未來如果需要測試更多的東西，你就會需要在這邊定義更多的method，來讓test code能夠取用這些method。這個技巧，常應用在當我們mock不屬於我們的東西(core data, network等等)上。

順道一提(副本也太多)，許多測試的原則都有提到，我們不能mock不屬於我們的東西(don’t mock things you don’t own)，但為甚麼我們現在卻用了一堆篇幅(加上一堆廢話)在講如何mock不屬於我們的東西？在Test-Driven iOS Development with Swift 3這本書裡面有提到，don’t mock things you don’t own指的是，我不能去mock third party的任何東西，因為我們不能確保這些東西，未來在更新版本之後，是不是會規格會一樣、行為模式也一樣。要是規格或行為模式有變，我們的測試輕則不過，重則會過了但是其實有邏輯上的錯誤，這是系統設計上的雷區，所以我們不mock這些我們不能控制的東西，但first-party的東西，相對穩定，並且是所有人都有共識的，這些是你可以去mock的。

回到剛剛的protocol，還記得原本標準的URLSession裡面，dataTask()回傳的東西嗎？原本回傳的是一個URLSessionDataTask，這又是一個不屬於我們的method，所以我們也要動手mock它！是不是你的雙手已經開始不由自主地打字了？沒錯，就是你想的那樣，我們需要一個URLSessionDataTaskProtocol！

protocol URLSessionDataTaskProtocol {
    func resume()
}

這個protocol更簡單，因為我們只會用到resume()，所以先定義它。

接下來，還有一個問題要解決，剛剛那兩個protocol，我們都直接套到我們的MockURLSession跟MockURLSessionDataTask上，並且我們也都乖乖地實作protocol所需要的method了，現在我們希望真實的URLSession跟URLSessionDataTask也符合這兩個protocol：

extension URLSession: URLSessionProtocol {}

extension URLSessionDataTask: URLSessionDataTaskProtocol {}

URLSessionDataTask沒甚麼大問題，它本來就有resume，並且長得一模一樣，所以直接套上這個protocol是ok的，但是就URLSession來說，原本的dataTask()回傳的是URLSessionDataTask，但我們新的dataTask()回傳的卻必須是URLSessionDataTaskProtocol，所以我們如果直接套上URLSessionProtocol，我們還是無法conform這個protocol，因為跟本就不存在這個method。We need to do something!

所以我們新增了一個method：

extension URLSession: URLSessionProtocol {
    func dataTask(with request: NSURLRequest, completionHandler: @escaping DataTaskResult) -> URLSessionDataTaskProtocol {
        return dataTask(with: request, completionHandler: completionHandler) as URLSessionDataTaskProtocol
    }
}

這個func做的事情，單純就是原本dataTask的接口，從原本回傳URLSessionDataTask，改成回傳URLSessionDataTaskProtocol，只有定義上有變化，本質上是完全不變的，關鍵就在於利用as將做簡單型別轉換，但完全不影響物件本身，只是為了conform這個protocol而存在。

最後，再回到剛剛的MockURLSession裡：

class MockURLSession {

    private (set) var lastURL: URL?

    func dataTask(with request: NSURLRequest, completionHandler: @escaping DataTaskResult) -> URLSessionDataTask {

        lastURL = request.url

        completionHandler(nextData, successHttpURLResponse(request: request), nextError)        

        return // dataTask
    }

}

那個return // dataTask，是時候給它名份(?)了：

class MockURLSession: URLSessionProtocol {

    var nextDataTask = MockURLSessionDataTask()

    private (set) var lastURL: URL?

    func dataTask(with request: NSURLRequest, completionHandler: @escaping DataTaskResult) -> URLSessionDataTaskProtocol {
    lastURL = request.url

        completionHandler(nextData, successHttpURLResponse(request: request), nextError)
        return nextDataTask
    }

}

所以這個MockURLSession的dataTask回傳的，就是一個MockURLSessionDataTask()，並且它是可以執行resume()的。這時候，我們的測試就可以被執行並且帥帥地通過了！

好了，第一個測試到目前為止已經正式完畢，接下來我們要來看第二個測試了！

Test Behavior

我們的第二個測試條件是：

要真的有發出request

沒錯，我們希望我們的子弟兵們都要乖乖做事，不要沒做但卻跟我說做了。所以我們希望這些子弟兵在檢查藥室有無子彈時，都要大聲地喊出”無”，表示他們真的有檢查（例子怪怪的）(有人真的會檢查？）（藥室在那裡？）

好的，現在這個測試跟剛剛不一樣，剛剛lastURL要測的是資料是不是正確，而這個測試需要知道的是，某個method有沒有真的被呼叫到。我們想知道request有沒有真的被發出去，用宅宅的話來說，就是dataTask().resume()有沒有真的被呼叫，也就是說，我們只要在我們的假環境的resume裡面，做個簡單的記錄，就可以知道它有沒有被call過了。

我們先寫好我們的測試code：

func test_get_resume_called() {

    let dataTask = MockURLSessionDataTask()
    session.nextDataTask = dataTask

    guard let url = URL(string: "https://mockurl") else {
        fatalError("URL can't be empty")
    }

    httpClient.get(url: url) { (success, response) in
        // Return data
    }

    XCTAssert(dataTask.resumeWasCalled)
}

resumeWasCalled就是我們想測試的目標，如果它是true，就表示resume()真的有被執行，因為執行resume的是URLSessionDataTask，所以我們把resumeWasCalled設計在dataTask裡面，而這個dataTask，很剛好，也是我們的人！

所以我們可以輕易地在裡面多加一個property：

class MockURLSessionDataTask: URLSessionDataTaskProtocol {
    private (set) var resumeWasCalled = false

    func resume() {
        resumeWasCalled = true
    }
}

只要有人在這個Mock環境裡呼叫resume()，resumeWasCalled就會變成true，我們就可以在測試code裡面判斷resume是不是有被呼叫了！

是不是很簡單阿！(不是)

Recap

在上面的文章中，我們了解到了：

1. 怎麼利用DI來抽換環境
2. 利用protocol來確保各種環境的接口是一致的
3. 怎樣做資料正確性的單元測試
4. 怎樣做行為的單元測試

所有的程式都擺在Github上，是一個Playground，歡迎下載來玩玩看，這個Playground另外多實做了一個test，是驗證get是不是有正確地把資料透過callback回傳回來，可以看看它舉一反三！

寫測試要有個心理準備，就是需要兩倍以上的前期開發時間，並且它不是萬靈單，你不會因為有了Unit Test，你就成為Bug-free man，就像你不會因為有了穩定的收入，就一定交得到女朋友一樣。但寫測試絕對是一件值得或者說需要被投入的事情，也是讓你的系統能夠永續的唯一關鍵。

最後，非常歡迎大家來幫我看一下這樣的測試邏輯是不是有問題，或者code有那邊可以加強的，沒有永遠正確的code，小弟非常樂意修改各種範例跟內容。有需要討論的地方也歡迎提出喔！

Bonus

最後最後，身為一個不是很強的工程師，希望自己能夠有更多機會了解怎樣架構程式，怎樣寫測試等等，小弟目前的想法是想找一些獨立開發者，共同維護一個簡單的project，並且互相code review，每次的commit都大概一兩個小時的量，然後一定要附上coverage 100%的test code，然後再review彼此的pull request。Project應該會是簡單的抓instagram圖的app之類的，不能賣錢的那種XD

有興趣的大大們，可以留下資料，可以找一天來kick off一下！XD

Happy coding!

Reference

這篇絕大多數的資料來自於

Mocking Classes You Don't Own

這篇語法大多是舊的，但概念是恆久不變的。

另外也參考了

Dependency Injection

文章非常巨細彌遺地列出了各種在iOS上的DI技巧，也包括了下一篇小弟會整理的Coredata Depedency Injection，值得一看(但文章真的很長XD)。

還有一本不錯的書

Test-Driven iOS Development with Swift

這本在amazon上買比較貴，可以去這裡買，小弟因為kindle太方便買的時候就沒有比價.....

歡迎來到真實世界目前總共有三集，歡迎一併觀賞！

歡迎來到真實世界 – Unit Test for Networking

歡迎來到真實世界 – Unit Test for Core Data

歡迎來到真實世界 – 原來是那個傳說中的MVVM阿

Generator跟Sequence是在許多語言之中常見的design pattern，有了這兩種patterns，你可以很清楚地把按需求取資料跟操作有順序的資料這兩件事情透過程式寫出來。

Swift在2.0時就已經提供了generatorType跟sequenceType兩種protocol來讓你實作，但在3.0之後，統一都改成了IteratorProtocol跟Sequence，所有跟generator有關的命名也都改成了Iterator。這讓這兩者的關係更為明確，而不再是長得像的兩個協定。

下面將從Iterator開始，利用範例來實做一個Swift的Sequence。

背景

現在要實做一台智慧型啤酒販賣機，販賣機依序裝著一罐一罐的啤酒。我們希望販賣機的UI能夠：

1. 按照容量列出機器裡的啤酒
2. 只列出大於400ml的啤酒
3. 整台機器的總藏酒毫升數

基本類別是當然是Beer 🍻。

struct Beer {
	var brandName: String    //品牌
	var volume: Int               //容量
}

接下來我們要一步一步透過Sequence完成這台販賣機的開發。首先，我們需要一個核心結構BeerContainer來裝所有的啤酒：

struct BeerContainer {
	let elements: [Beer]
	var i = 0

	init(elements: [Beer]) {
		self.elements = elements
	}
}

變數elements是一個Array，放著我們的🍻。我們希望這個container不只能存東西，還能在我們需要的時候，一筆一筆地把啤酒列出來。這樣的行為模式在Swift就叫做Iterator，指的就是在遍歷某個容器時，，不是先把容器裡的物件全部攤開讓你去traverse，而是在下next()之後，才去計算它的下一筆資料並回傳。想要讓我們的BeerContainer能夠成為一個Iterator，就需要實作IteratorProtocol。

IteratorProtocol

IteratorProtocol長這樣：

protocol IteratorProtocol {
	associatedtype Element
	mutating func next() -> Element?
}

我們需要實作的method就只有一個，就是next()。這個next()需要在每次被呼叫的時候，都回傳下一筆資料，並且把這次的資料記下來，讓下次呼叫next()時能夠成功抓到再下一筆資料。在這邊的例子，我們利用BeerContainer的變數i來代表我們目前所在資料的位置，每call一次next()，我們都讓i加一，這樣就可以一次輸出一筆，並且一筆一筆往下移。

extension BeerContainer: IteratorProtocol {
	typealias Element = Beer

	mutating func next() -> Element? {
		defer {
			i+=1
		}
		return i<elements.count ? elements[i] : nil
	}
}

上面的程式中有幾個點要注意：

1. Element是這個protocol的associated type，在實作時我們需要明確指定我們的這個iterator是要針對那一種物件操作。
2. next()這個method是mutating的，也就是說在執行這個method後，會改變這個物件裡的某個變數，這點帶出了iterator的一個非常重要的特性，就是它本身不是immutable的，每次call next()都會有不一樣的結果。
3. defer是一個Swift的神奇語法，代表的是一個closure會在這個scope跑完之後，才執行closure裡面的內容。

在next()之中，每次執行都會回傳elements[i]，並且把i加一。

以下是實際上線的狀況：

let aOrionBeer = Beer(brandName: "Orion", volume: 300)
let aSaporoBeer = Beer(brandName: "Saporo", volume: 380)
let aTaiwanBeer = Beer(brandName: "TaiwanBeer", volume: 330)
let aAsahiBeer = Beer(brandName: "Asahi", volume: 420)


var aBeerContainer = BeerContainer(elements: [ aOrionBeer, aSaporoBeer, aTaiwanBeer, aAsahiBeer ])

// i=0
print(aBeerContainer.next())
// Orion: 300 ml, i=1

print(aBeerContainer.next())
// Saporo: 380 ml, i=2

print(aBeerContainer.next())
// TaiwanBeer: 330 ml, i=3

print(aBeerContainer.next())
// Asahi: 400 ml, i=4

print(aBeerContainer.next())
// nil, i=5

每次呼叫next()，這個iterator才會回傳目前i指向的值，並且把i加一為下一次呼叫next()做準備。在呼叫的過程中，i一直都在改變，也就是這個BeerContainer物件本身一直都在變化，等全部都取完之後，就再也拿不到值了。

上面的code可以寫成更常見的型式：

while let aBeer = aBeerMContainer.next() {
	print(aBeer)
}

到這邊我們就了解了IteratorProtocol要怎樣實作，可以按一個鈕next()就噴出一罐啤酒了😎

但Iterator只是一個基本的資料結構，如果我們想要做一些如排序、過濾等等變化，就必須要再把Iterator打包成更高層的資料結構：Sequence。

Sequence protocol

在Swift之中，Sequence代表的是一個有序的資料結構。像我們常見的Array就有符合Sequence，可以用for..in的方法來取用內容：

let bugs = ["Aphid", "Bumblebee", "Cicada", "Damselfly", "Earwig"]
for bug in bugs {
	print(bug)
}

你可以把Sequence理解成像Array一樣的有序結構，而Iterator比較像是一個需要呼叫才會有動靜的指標。

接下來，我們要來動手製作我們的VendorMachine了！

struct VendorMachine {
	let elements: [Beer]
}

好的，現在這台販賣機毫無疑問，就是一台可以裝東西的機器。再來我們需要讓它成為Sequence，才能夠做出對裡面的啤酒排序、選擇等等動作。要成為一個Sequence非常簡單，只需要conform一個methodmakeIterator()：

protocol Sequence {
	associatedtype Iterator : IteratorProtocol    
	func makeIterator() -> Iterator
}

這個makeIterator()是做甚麼用的？Sequence的核心，就是這個Iterator，Sequence靠著Iterator來做到依序讀取資料，並且在這樣的基礎之上，再加入許多方便使用的方法如map()、reduce()、跟filter()。

讓我們來把VendorMachine實作成 Sequence吧！下面是一個非常基本的實作：

extension VendorMachine: Sequence {
	typealias Iterator = IndexingIterator<[Beer]>

	func makeIterator() -> Iterator {
		return elements.makeIterator()
	}
}

typealias的作用，跟我們在IteratorProtocol章節提到的一樣，是為了指定實作型別用的。在這個實作中，我們取了個捷徑，直接使用Array中已經定義好的IndexingIterator來當做我們的Iterator。IndexingIterator就是一個會按照index=1, 2, 3, 4...來讀取資料的Iterator，其實功能等同於我們上面的BeerContainer。利用這個既有的Iterator，我們設定我們的Sequence，要利用這個Iterator來執行Sequence的其它method。終於可以來實作我們的啤酒販賣機了！

首先先建立好我們的VendorMachine，並且塞一些啤酒進去：

let aMachine = VendorMachine(elements: [ aOrionBeer, aSaporoBeer, aTaiwanBeer, aAsahiBeer ])

還記得我們的需求嗎？

1. 按照容量列出機器裡的啤酒

這邊我們要做的就是把VendorMachine裡的東西排序，身為一個Sequence，Swift有提供sorted()讓Sequence能夠回傳排序過的資料，使用方式如下：

let sortedBeers = aMachine.sorted { $0.volume>$1.volume }
// [Asahi: 420 ml, Saporo: 380 ml, TaiwanBeer: 330 ml, Orion: 300 ml]

sorted這個method用了不少Swift syntactic sugar，如果不熟的可以參考小弟拙作Swift Syntactic Sugar 偏方可恥但有用，懶得說明就用工商服務取代，是一個blogger應有的態度。

回到正題，sorted這個method會回傳排序過的Sequence內容，排序的方式是甚麼？就是利用sorted唯一的參數by，它是一個回傳Bool的closure，sorted method會依照這邊回傳的Bool來判斷兩個元素之間的大小關係。

1. 只列出大於400ml的啤酒

這裡則是會使用Sequence定義好的filter()這個method，這個method只有一個closure參數，利用closure回傳的Bool，來決定那些元素要留下：

let largeBeers = aMachine.filter { $0.volume>400 }
// [Asahi: 420 ml]

1. 整台機器的總藏酒毫升數

相信大家對reduce都已經很熟悉了，不熟的一樣可以參考上面提到的拙作(不放棄打歌)。下面這個程式就利用reduce，把所有的volume都總和起來並且輸出：

let totalVolume = aMachine.reduce(0) { return $0+$1.volume }
// 1430

以上就是一個Sequence所會有的基本功能，而我們也利用這些基本功能完成了我們的任務！🍻 🍻 🍻

等等，這個東西跟存成[ Beer ]有甚麼不一樣？沒錯，正如冰雪聰明的你所猜到的，這完全就是一個Array的簡易實作，並且我們還取巧地用了Array的Iterator來達到我們的目的，來摸著你的良心，請問你想這樣就交差嗎？想！(完全沒考慮)

接下來要真正進入這篇冗長文章的主題(是有多少主題)，幫Sequence裝上自製的Iterator，成為真正的天然手作Sequence。我們把上面的implementation改成下面這樣，把剛剛寫好的BeerContainer裝到makeIterator()裡面：

extension VendorMachine: Sequence {
	typealias Iterator = BeerContainer

	func makeIterator() -> Iterator {
		return BeerContainer(elements: self.elements)
	}
}

這樣我們就完成了我們的販賣機，並且用自己寫好的Iterator來實現Sequence了！(主題不到十行)

AnyIterator

接下來進行同場加映，也就是真正實用上最常遇到的Sequence跟Iterator搭配用法。一般實用上我們不太會為了這個Sequence特別立一個Iterator，而是會利用一個AnyIterator，來簡單地把makeIterator()給實作出來。

AnyIterator是一種Iterator，它可以輸入一個closure，當成是這個Iterator的next()。下面的程式會在AnyIterator的closure之中，實作一個每跑一次next()就把index加一的function：

struct VendorMachine: Sequence {
	typealias Iterator = AnyIterator<Beer>

	let elements: [Beer]

	func makeIterator() -> Iterator {
		var i = self.elements.startIndex
		return AnyIterator {
			defer {
				i+=1
			}
			return i<self.elements.count ? self.elements[i] : nil
		}
	}
}

上面就是把整個iterator寫在makeIterator裡面的例子，在AnyIterator之中，每跑一次這個closure，就會回傳elements之中第i個變數，並且i會被加一。這樣我們就成功地把整個BeerContainer搬到這個makeIterator裡面了！其它的code都跟我們在BeerContainer上實作的一樣，只是要注意的是，AnyIterator的參數是一個@escaping closure，所以必須要明確地把self給標出來。

以上就是Iterator跟Sequence的介紹，故事的最後，要來做一下總結：

1. Iterator就是一個按需求依序噴出資料的容器。
2. Sequence則是利用Iterator實作出來的、更高階的有序資料結構。
3. 實作了Sequence之後，就能夠使用map、reduce、filter等等method。
4. AnyIterator能夠把next()拉到外面成為一個參數，方便Iterator的建立。

如果有誤的話歡迎隨時提出來，也歡迎討論喔！所有的程式碼都可以在這邊抓得到，是一個Playground。

PS 1. Iterator pattern很常被用在像讀取大檔案這種無法一次全部取出來，只能一筆一筆列的情況，上面的實作有許多更方便的做法，我們只是希望透過簡化使用方式來解釋這個pattern。

PS 10. Sequence在定義上，並不能完全當成像Array一樣使用，甚麼意思？以下是官方範例：

for element in sequence {
	if ... some condition { break }
}

for element in sequence {
	// No defined behavior
}

第一個for..in就正常使用它，而在第二個for..in，如果對象是一個Array的話，那就是從頭到尾遍歷一次，但如果是個Sequence，裡面的行為模式就是未定義！也就是說，Swift不保證Sequence在重覆讀取時資料會維持一樣，如果你希望它可以像Array一樣能重覆存取，有個protocol需要被實作：Collection。

PS 11. Collection我們就等春暖花開時再來寫吧....

PS 100. Norah Jones這局得一百分！貢獻了這篇文章100%的背景音樂！聽首歌吧：https://www.youtube.com/watch?v=ROditq3L8w4

PS 101. 如果你的生存三元素是陽光、空氣、啤酒，那歡迎來分享在台北的求生之路。

參考資料

https://developer.apple.com/reference/swift/sequence#protocol-requirements

https://medium.com/swift-programming/swift-sequences-ce22d76f120c

http://nshipster.com/swift-collection-protocols/

https://www.raywenderlich.com/139591/building-custom-collection-swift

https://www.objc.io/books/advanced-swift/preview/#sequence