DEV Community: Tamas Dancsi

Feature Modules in iOS

Tamas Dancsi — Thu, 11 Jul 2024 09:41:29 +0000

Feature Modules in iOS

In modern iOS development, organizing code into feature modules can greatly enhance the reusability and maintainability of your app. This article will guide you through creating feature modules using a simple example: FlowerList and FlowerDetails features. We will explore the main layers in an iOS project: View, ViewModel, Use Case, Repository, and Service, and implement async/await for service calls.

The whole source code is available on Github.

Main Layers in iOS Development Projects

View: Handles the UI components and user interactions.
ViewModel: Acts as an intermediary between the View and the Use Case, managing UI-related data.
Use Case: Encapsulates the business logic of a particular feature.
Repository: Manages data operations and acts as a single source of truth.
Service: Handles network or database operations.

Shared data manipulation layer

FlowerRepository

import Foundation

protocol FlowerRepository {

    func getFlowers() async -> [Flower]
    func getFlowerDetails(id: Int) async -> Flower
}

class FlowerRepositoryImpl: FlowerRepository {

    private let flowerService: FlowerService

    init(flowerService: FlowerService) {
        self.flowerService = flowerService
    }

    func getFlowers() async -> [Flower] {
        await flowerService.fetchFlowers()
    }

    func getFlowerDetails(id: Int) async -> Flower {
        await flowerService.fetchFlowerDetails(id: id)
    }
}

FlowerService Protocol and Implementation

protocol FlowerService {

    func fetchFlowers() async -> [Flower]
    func fetchFlowerDetails(id: Int) async -> Flower
}

class FlowerServiceImpl: FlowerService {

    func fetchFlowers() async -> [Flower] {
        /// Simulating network call
        [Flower(id: 1, name: "Rose"), Flower(id: 2, name: "Tulip")]
    }

    func fetchFlowerDetails(id: Int) async -> Flower {
        /// Simulating network call
        Flower(id: id, name: "Random flower", description: "A beautiful flower")
    }
}

Creating Feature Modules

FlowerList Feature

FlowerListView

import SwiftUI

struct FlowerListView: View {

    @StateObject var viewModel: FlowerListViewModel

    var body: some View {
        NavigationStack {
            List(viewModel.flowers) { flower in
                NavigationLink {
                    Assembler.default.flowerDetailsView(id: flower.id)
                } label: {
                    Text(flower.name)
                }
            }
            .onAppear {
                Task {
                    await viewModel.fetchFlowers()
                }
            }
        }
    }
}

FlowerListViewModel

import Combine

class FlowerListViewModel: ObservableObject {

    @Published var flowers: [Flower] = []

    private let flowerListUseCase: FlowerListUseCase

    init(flowerListUseCase: FlowerListUseCase) {
        self.flowerListUseCase = flowerListUseCase
    }

    @MainActor
    func fetchFlowers() async {
        flowers = await flowerListUseCase.getFlowers()
    }
}

FlowerListUseCase

import Foundation

protocol FlowerListUseCase {

    func getFlowers() async -> [Flower]
}

class FlowerListUseCaseImpl: FlowerListUseCase {

    private let flowerRepository: FlowerRepository

    init(flowerRepository: FlowerRepository) {
        self.flowerRepository = flowerRepository
    }

    func getFlowers() async -> [Flower] {
        await flowerRepository.getFlowers()
    }
}

FlowerDetails Feature

FlowerDetailsView

import SwiftUI

struct FlowerDetailsView: View {

    @StateObject var viewModel: FlowerDetailsViewModel

    let id: Int

    var body: some View {
        VStack {
            if let flower = viewModel.flower {
                Text("\(flower.id)")
                Text(flower.name)
                Text(flower.description ?? "")
            }
        }
        .onAppear {
            Task {
                await viewModel.fetchFlowerDetails(id: id)
            }
        }
    }
}

FlowerDetailsViewModel

import Combine

class FlowerDetailsViewModel: ObservableObject {

    @Published var flower: Flower?

    private let flowerDetailsUseCase: FlowerDetailsUseCase

    init(flowerDetailsUseCase: FlowerDetailsUseCase) {
        self.flowerDetailsUseCase = flowerDetailsUseCase
    }

    @MainActor
    func fetchFlowerDetails(id: Int) async {
        flower = await flowerDetailsUseCase.getFlowerDetails(id: id)
    }
}

FlowerDetailsUseCase

protocol FlowerDetailsUseCase {

    func getFlowerDetails(id: Int) async -> Flower
}

class FlowerDetailsUseCaseImpl: FlowerDetailsUseCase {

    private let flowerRepository: FlowerRepository

    init(flowerRepository: FlowerRepository) {
        self.flowerRepository = flowerRepository
    }

    func getFlowerDetails(id: Int) async -> Flower {
        await flowerRepository.getFlowerDetails(id: id)
    }
}

Conclusion

By organizing your iOS project into feature modules with distinct layers (View, ViewModel, Use Case, Repository, and Service), you create a clean and maintainable codebase. The FlowerList and FlowerDetails features demonstrate how to keep related business logic within their respective modules, ensuring reusability and separation of concerns. Using async/await for service calls modernizes the code, making it more efficient and easier to read.

Async/await and SwiftUI

Tamas Dancsi — Thu, 20 Jun 2024 12:28:34 +0000

Using Swift's async/await with SwiftUI can greatly simplify handling asynchronous tasks, such as fetching data from a network. Here's a basic example that includes a view, view model, use-case, repository, and service layer to illustrate how these components interact.

See my Github project for the tested source-code.

1. Service Layer

First, let's define a service layer responsible for fetching data. This could be a simple API service. APIService conforms to APIServiceProtocol and simulates fetching data from an API.

import Foundation

protocol APIServiceProtocol {
    func fetchData() async throws -> String
}

class APIService: APIServiceProtocol {
    func fetchData() async throws -> String {
        // Simulate network delay
        try await Task.sleep(nanoseconds: 1_000_000_000)
        return "Data from API"
    }
}

2. Repository Layer

The repository layer abstracts the data source (service layer) from the rest of the application. Repository conforms to RepositoryProtocol and uses the APIService to get data.

import Foundation

protocol RepositoryProtocol {
    func getData() async throws -> String
}

class Repository: RepositoryProtocol {
    private let apiService: APIServiceProtocol

    init(apiService: APIServiceProtocol = APIService()) {
        self.apiService = apiService
    }

    func getData() async throws -> String {
        return try await apiService.fetchData()
    }
}

3. Use-Case Layer

The use-case layer contains the business logic. In this case, it fetches data using the repository. FetchDataUseCase conforms to FetchDataUseCaseProtocol and uses the repository to fetch data.

import Foundation

protocol FetchDataUseCaseProtocol {
    func execute() async throws -> String
}

class FetchDataUseCase: FetchDataUseCaseProtocol {
    private let repository: RepositoryProtocol

    init(repository: RepositoryProtocol = Repository()) {
        self.repository = repository
    }

    func execute() async throws -> String {
        return try await repository.getData()
    }
}

4. ViewModel

The view model interacts with the use-case layer and provides data to the view. DataViewModel is an ObservableObject that handles data fetching asynchronously using the use-case. It manages loading state, data, and potential error messages. Using async/await in this way makes the code more readable and easier to follow compared to traditional completion handler approaches. The @MainActor attribute ensures that UI updates happen on the main thread.

import Foundation
import SwiftUI

@MainActor
class DataViewModel: ObservableObject {
    @Published var data: String = ""
    @Published var isLoading: Bool = false
    @Published var errorMessage: String?

    private let fetchDataUseCase: FetchDataUseCaseProtocol

    init(fetchDataUseCase: FetchDataUseCaseProtocol = FetchDataUseCase()) {
        self.fetchDataUseCase = fetchDataUseCase
    }

    func loadData() async {
        isLoading = true
        errorMessage = nil

        do {
            let result = try await fetchDataUseCase.execute()
            data = result
        } catch {
            errorMessage = error.localizedDescription
        }

        isLoading = false
    }
}

5. View

Finally, the view observes the view model and updates the UI accordingly. ContentView observes DataViewModel and displays a loading indicator, the fetched data, or an error message based on the state of the view model.

import SwiftUI

struct ContentView: View {
    @StateObject private var viewModel = DataViewModel()

    var body: some View {
        VStack {
            if viewModel.isLoading {
                ProgressView()
            } else if let errorMessage = viewModel.errorMessage {
                Text("Error: \(errorMessage)")
            } else {
                Text(viewModel.data)
            }
        }
        .onAppear {
            Task {
                await viewModel.loadData()
            }
        }
        .padding()
    }
}

SOLID explained with iOS examples

Tamas Dancsi — Thu, 20 Jun 2024 09:14:05 +0000

The SOLID principles are a set of guidelines for designing software that is easy to maintain and extend.

1. Single Responsibility Principle (SRP)

A class should have only one reason to change, meaning it should only have one job or responsibility.

// WRONG: A class that handles both user authentication and user data storage
class UserManager {
    func authenticateUser(username: String, password: String) -> Bool {
        // Authentication logic
        return true
    }

    func saveUserDetails(user: User) {
        // Save user details logic
    }
}

// CORRECT: Separate classes for authentication and data storage
class Authenticator {
    func authenticateUser(username: String, password: String) -> Bool {
        // Authentication logic
        return true
    }
}

class UserStorage {
    func saveUserDetails(user: User) {
        // Save user details logic
    }
}

2. Open/Closed Principle (OCP)

Software entities should be open for extension but closed for modification.

// WRONG: A class that needs to be modified to support new types of notifications
class NotificationManager {
    func sendNotification(type: String) {
        if type == "email" {
            // Send email notification
        } else if type == "sms" {
            // Send SMS notification
        }
    }
}

// CORRECT: Extendable notification types using protocol
protocol Notification {
    func send()
}

class EmailNotification: Notification {
    func send() {
        // Send email notification
    }
}

class SMSNotification: Notification {
    func send() {
        // Send SMS notification
    }
}

class NotificationManager {
    func sendNotification(notification: Notification) {
        notification.send()
    }
}

3. Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types without altering the correctness of the program.

// WRONG: A subclass that breaks the functionality of the superclass
class Bird {
    func fly() {
        print("Flying")
    }
}

class Ostrich: Bird {
    override func fly() {
        // Ostrich can't fly, so this method should not exist here
        fatalError("Ostriches can't fly!")
    }
}

// CORRECT: Using protocol to define a contract for flying birds
protocol Flyable {
    func fly()
}

class Sparrow: Flyable {
    func fly() {
        print("Flying")
    }
}

class Ostrich {
    // Ostrich does not conform to Flyable because it can't fly
}

4. Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they do not use.

// WRONG: A single interface with too many responsibilities
protocol Worker {
    func work()
    func eat()
}

class Developer: Worker {
    func work() {
        // Coding
    }

    func eat() {
        // Eating lunch
    }
}

class Robot: Worker {
    func work() {
        // Coding
    }

    func eat() {
        // Robots don't eat, so this method is not applicable
    }
}

// CORRECT: Separate interfaces for different responsibilities
protocol Workable {
    func work()
}

protocol Eatable {
    func eat()
}

class Developer: Workable, Eatable {
    func work() {
        // Coding
    }

    func eat() {
        // Eating lunch
    }
}

class Robot: Workable {
    func work() {
        // Coding
    }
}

5. Dependency Inversion Principle (DIP)

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

// WRONG: High-level module depends on low-level module
class Database {
    func save() {
        // Save to database
    }
}

class UserRepository {
    private let database = Database()

    func saveUser() {
        database.save()
    }
}

// CORRECT: High-level module depends on an abstraction
protocol Storage {
    func save()
}

class Database: Storage {
    func save() {
        // Save to database
    }
}

class UserRepository {
    private let storage: Storage

    init(storage: Storage) {
        self.storage = storage
    }

    func saveUser() {
        storage.save()
    }
}

Test-driven development in iOS

Tamas Dancsi — Thu, 19 Mar 2020 10:47:58 +0000

"Could you update the design for that button only on the settings screen? Don't think too much about it though, it should have been released yesterday."

I'm sure it sounds familiar. There are times in many projects' lifecycle when pressing changes are necessary, but thinking too much about the details is "not that important". This mostly ends up in writing spaghetti code and the outcome will be bugs in your production code. Unless you write good enough tests, of course, to keep you safe from them.

What is TDD?

Test-driven development is all over the place. The basic idea is you write tests first, before any actual code. Tests will fail at first, so you need to write just enough code to make them pass. Then you can refactor your code without changing the behavior so your tests still pass.

Many argue it's too bureaucratic, which is somewhat true. At first, it definitely slows down the implementation process, so make sure to dedicate some time for the learning phase.

Once that's over though, adding features will become natural and you will be able to enjoy the beautiful side-effects. Your code will become self-documenting as reading your test-cases should describe exactly what your supporting code does.

Your code coverage will be improved, so issues like the one mentioned above will let you sleep better in the evening. Similarly, implementing bigger refactorings will also get easier thanks to the better coverage.

Getting started

The source-code for the article is available on Github.

The first thing to do is coming up with a concept. Without writing any code, just thinking through what we're about to build. Our showcase project is a diary. The basic features are the following:

New entries can be added
Existing entries can be updated
Existing entries can be removed

Without implementing anything, think through what will we need based on our concept so far (since the intention of this post is to give you an introduction, we'll not overcomplicate the main app design here):

We'll be working with some kind of entry objects, that will be stored in some data source
We'll for sure have two screens: the entry list and the entry detail screen to edit entries
It would be great to have a factory that prepares our screens and a router to handle the app navigation

Writing tests

Once we know what we want and we have an overview in our head, we can start adding our tests and their minimum supporting code.

1. Testing the data source

Let's add a test to check if our data source is empty by default. Let's expose the entries already sorted to make sure the newest entry will always be the first.

func test_entries_emptyByDefault() {
    let dataSource = DiaryDataSource()
    XCTAssertEqual(dataSource.sortedEntries.count, 0)
}

When you run the test, it will of course fail. The minimal required code to fix this could be this.

class DiaryDataSource {

    var sortedEntries: [AnyObject] {
        []
    }
}

Let's add a test to see if saving entries works. For that let's introduce an actual model first to describe our entries instead of AnyObject.

struct Entry {

    // For the scope of the demo project, `date` behaves as the unique key
    let date: Date
    var text: String
}

We can add the test now.

func test_entries_addsEntry() {
    let testDate1 = Date()
    let testText1 = "First entry text"
    let testEntry1 = Entry(date: testDate1, text: testText1)

    let dataSource = DiaryDataSource()
    dataSource.save(entry: testEntry1)

    XCTAssertEqual(dataSource.sortedEntries.count, 1)
}

We have a failing test, great! Let's implement saving in our data source.

class DiaryDataSource {

    fileprivate var entries: [Entry] = []

    var sortedEntries: [Entry] {
        entries
    }

    func save(entry: Entry) {
        entries.removeAll(where: { $0.date == entry.date })
        entries.append(entry)
    }
}

Let's create another test to make sure our entry is inserted only once if we try to insert it multiple times.

func test_entries_addsEntry_onlyOnce() {
    let testDate1 = Date()
    let testText1 = "First entry text"
    let testEntry1 = Entry(date: testDate1, text: testText1)

    let dataSource = DiaryDataSource()
    dataSource.save(entry: testEntry1)
    dataSource.save(entry: testEntry1)
    dataSource.save(entry: testEntry1)

    XCTAssertEqual(dataSource.sortedEntries.count, 1)
}

Perfect, our tests succeeded. If we check it closer, our second test actually also tests our single insertion use-case, so we can delete that one.

We can now add the test to check if our sorting works.

func test_entries_addsEntry_keepsOrder() {
    let dataSource = DiaryDataSource()

    let testDate1 = Date()
    var testDate2: Date { testDate1.addingTimeInterval(3600 * 1) }
    var testDate3: Date { testDate1.addingTimeInterval(3600 * 2) }

    let testText1 = "First entry text"
    let testText2 = "Second entry text"
    let testText3 = "Third entry text"

    let testEntry1 = Entry(date: testDate1, text: testText1)
    let testEntry2 = Entry(date: testDate2, text: testText2)
    let testEntry3 = Entry(date: testDate3, text: testText3)

    dataSource.save(entry: testEntry2)
    dataSource.save(entry: testEntry3)
    dataSource.save(entry: testEntry1)

    let entries = dataSource.sortedEntries
    XCTAssertEqual(entries.count, 3)
    XCTAssertEqual(entries[0].date, testDate3)
    XCTAssertEqual(entries[0].text, testText3)
    XCTAssertEqual(entries[1].date, testDate2)
    XCTAssertEqual(entries[1].text, testText2)
    XCTAssertEqual(entries[2].date, testDate1)
    XCTAssertEqual(entries[2].text, testText1)
}

Another failing test, great! The reason is that we didn't implement sorting, yet, let's add that now.

class DiaryDataSource {

    fileprivate var entries: [Entry] = []

    var sortedEntries: [Entry] {
        entries.sorted { $0.date > $1.date }
    }

    func save(entry: Entry) {
        entries.removeAll(where: { $0.date == entry.date })
        entries.append(entry)
    }
}

The test succeeds now nicely, but there's a lot of boilerplate code in it. To shrink the test size, let's move the test data to a common XCTestCase class and inherit our tests from that one.

class BaseTestCase: XCTestCase {

    // MARK: Test data

    let testDate1 = Date()
    var testDate2: Date { testDate1.addingTimeInterval(3600 * 1) }
    var testDate3: Date { testDate1.addingTimeInterval(3600 * 2) }

    let testText1 = "First entry text. This one is very long to make sure we also test the case when the entry's message is too long for the cell, so it gets trimmed"
    let testText2 = "Second entry text"
    let testText3 = "Third entry text"

    lazy var testEntry1: Entry = { Entry(date: testDate1, text: testText1) }()
    lazy var testEntry2: Entry = { Entry(date: testDate2, text: testText2) }()
    lazy var testEntry3: Entry = { Entry(date: testDate3, text: testText3) }()

    let dataSource = DiaryDataSource()
}

Let's refactor our tests so far, they look a lot cleaner now.

class DiaryDataSourceTests: BaseTestCase {

    func test_entries_emptyByDefault() {
        XCTAssertEqual(dataSource.sortedEntries.count, 0)
    }

    func test_entries_addsEntry_onlyOnce() {
        dataSource.save(entry: testEntry1)
        dataSource.save(entry: testEntry1)
        dataSource.save(entry: testEntry1)

        XCTAssertEqual(dataSource.sortedEntries.count, 1)
    }

    func test_entries_addsEntry_keepsOrder() {
        dataSource.save(entry: testEntry2)
        dataSource.save(entry: testEntry3)
        dataSource.save(entry: testEntry1)

        let entries = dataSource.sortedEntries
        XCTAssertEqual(entries.count, 3)
        XCTAssertEqual(entries[0].date, testDate3)
        XCTAssertEqual(entries[0].text, testText3)
        XCTAssertEqual(entries[1].date, testDate2)
        XCTAssertEqual(entries[1].text, testText2)
        XCTAssertEqual(entries[2].date, testDate1)
        XCTAssertEqual(entries[2].text, testText1)
    }
}

Let's move on now to removing entries from the store. The first test should check if the store gets empty after removing the only entry from it.

func test_entries_removesAll() {
    dataSource.save(entry: testEntry1)
    dataSource.remove(entry: testEntry1)

    XCTAssertEqual(dataSource.sortedEntries.count, 0)
}

We're happy, it's failing, let's add removal to our data source as well.

// Add this to DiaryDataSource.swift
func remove(entry: Entry) {
    entries.removeAll(where: { $0.date == entry.date })
}

Let's add another one to make sure the right entry is being removed from the store.

func test_entries_removesFirst() {
    dataSource.save(entry: testEntry1)
    dataSource.save(entry: testEntry2)
    dataSource.remove(entry: testEntry1)

    let entries = dataSource.sortedEntries
    XCTAssertEqual(entries.count, 1)
    XCTAssertEqual(entries[0].date, testDate2)
    XCTAssertEqual(entries[0].text, testText2)
}

This doesn't fail, so we might as well remove our previous test as it's covered by this one. Let's add a test case to cover updating entries as well.

func test_entries_updatesEntry() {
    var entry = testEntry1
    dataSource.save(entry: entry)

    entry.text = testUpdatedText
    dataSource.save(entry: entry)
    let entries = dataSource.sortedEntries

    XCTAssertEqual(entries.count, 1)
    XCTAssertEqual(entries[0].date, testDate1)
    XCTAssertEqual(entries[0].text, testUpdatedText)
}

Let's add a new test property in our base test case.

let testUpdatedText = "Updated entry text"

Perfect, we're done with our data source, it's time to test the router.

2. Testing the router

The first test should cover if the router navigates to the diary list controller properly.

func test_displaysDiaryListController() {
    router.displayDiaryList()

    XCTAssertEqual(navigationController.viewControllers.count, 1)
    XCTAssertEqual(navigationController.viewControllers.first, diaryListViewController)
}

We'll need some helpers for this. First, I'd like to mock UIKit's UINavigationController to get rid of its animations. Of course, by this, we're changing default behavior, so feel free to skip this step.

class MockNavigationController: UINavigationController {

    override func pushViewController(_ viewController: UIViewController, animated: Bool) {
        super.pushViewController(viewController, animated: false)
    }

    override func popViewController(animated: Bool) -> UIViewController? {
        super.popViewController(animated: false)
    }
}

Then we'll need an empty router to get rid of the errors.

class DiaryRouter {

    fileprivate let navigationController: UINavigationController

    init(navigationController: UINavigationController) {
        self.navigationController = navigationController
    }

    func displayDiaryList() {}
}

We can add some test properties to our base test case to silence all errors now.

let navigationController = MockNavigationController()
let diaryListViewController = UIViewController()

lazy var router: DiaryRouter = {
    DiaryRouter(navigationController: navigationController)
}()

We have a failing test, perfect. Let's introduce a view controller factory interface and create an app-specific instance from it. Then we can inject this to our router, so it can reuse the view controllers the factory is creating.

protocol ViewControllerFactory {

    var dataSource: DiaryDataSource { get }

    func diaryListViewController(router: DiaryRouter) -> UIViewController
}

final class DiaryViewControllerFactory: ViewControllerFactory {

    let dataSource: DiaryDataSource

    init(dataSource: DiaryDataSource) {
        self.dataSource = dataSource
    }

    func diaryListViewController(router: DiaryRouter) -> UIViewController {
        return UIViewController()
    }
}

We can then extend our router as well.

final class DiaryRouter {

    fileprivate let navigationController: UINavigationController
    fileprivate let factory: ViewControllerFactory

    init(navigationController: UINavigationController, factory: ViewControllerFactory) {
        self.navigationController = navigationController
        self.factory = factory
    }

    func displayDiaryList() {
        let controller = factory.diaryListViewController(router: self)
        navigationController.viewControllers = [controller]
    }
}

Let's then mock our factory in the test target.

class MockViewControllerFactory: ViewControllerFactory {

    let dataSource: DiaryDataSource

    init(dataSource: DiaryDataSource) {
        self.dataSource = dataSource
    }

    fileprivate var stubbedDiary: UIViewController? = nil

    func stub(diaryListWith viewController: UIViewController) {
        stubbedDiary = viewController
    }

    func diaryListViewController(router: DiaryRouter) -> UIViewController {
        guard let stubbedDiary = stubbedDiary else {
            fatalError("View controllers need to be stubbed for the tests")
        }
        return stubbedDiary
    }
}

Lastly, we can stub our view controller and update our test properties in our base test case.

lazy var factory: MockViewControllerFactory = {
    MockViewControllerFactory(dataSource: dataSource)
}()

lazy var router: DiaryRouter = {
    DiaryRouter(navigationController: navigationController, factory: factory)
}()

override func setUp() {
    // Force-loading the views
    let _ = diaryListViewController.view

    // Stubbing the view controllers
    factory.stub(diaryListWith: diaryListViewController)
}

Great, all tests are green now. Let's add another test to make sure our router navigates to the list only once, then we can get rid of the first test since it will be deprecated by it.

func test_displaysDiaryListController_onlyOnce() {
    router.displayDiaryList()
    router.displayDiaryList()
    router.displayDiaryList()

    XCTAssertEqual(navigationController.viewControllers.count, 1)
    XCTAssertEqual(navigationController.viewControllers.first, diaryListViewController)
}

Let's add a test to verify the entry detail screen gets displayed when the user taps the add button. We will add a bar button item to the top right on the list. Our excpectation is, that the router will present the new entry screen once we tap on it.

func test_displaysNewEntryController_fromList() {
    router.displayDiaryList()
    diaryListViewController.navigationItem.rightBarButtonItem?.simulateTap()

    XCTAssertEqual(navigationController.viewControllers.count, 2)
    XCTAssertEqual(navigationController.viewControllers.first, diaryListViewController)
    XCTAssertEqual(navigationController.viewControllers.last, newEntryViewController)
}

We can add a helper extension in the test target to simulate the tap with a nicer api.

extension UIBarButtonItem {

    func simulateTap() {
        guard let action = action else { return }
        target?.performSelector(onMainThread: action, with: nil, waitUntilDone: true)
    }
}

Let's update our factory to support creating the new entry screen.

protocol ViewControllerFactory {

    var dataSource: DiaryDataSource { get }

    func diaryListViewController(router: DiaryRouter) -> UIViewController
    func newEntryViewController(router: DiaryRouter) -> UIViewController
}

class MockViewControllerFactory: ViewControllerFactory {

    let dataSource: DiaryDataSource

    init(dataSource: DiaryDataSource) {
        self.dataSource = dataSource
    }

    fileprivate var stubbedDiary: UIViewController? = nil
    fileprivate var stubbedNewEntry: UIViewController? = nil

    func stub(diaryListWith viewController: UIViewController) {
        stubbedDiary = viewController
    }

    func stub(newEntryWith viewController: UIViewController) {
        stubbedNewEntry = viewController
    }

    func diaryListViewController(router: DiaryRouter) -> UIViewController {
        guard let stubbedDiary = stubbedDiary else {
            fatalError("View controllers need to be stubbed for the tests")
        }
        return stubbedDiary
    }

    func newEntryViewController(router: DiaryRouter) -> UIViewController {
        return stubbedNewEntry ?? UIViewController()
    }
}

Then update our base test case with the new test properties.

let newEntryViewController = UIViewController()

override func setUp() {
    // Force-loading the views
    let _ = diaryListViewController.view
    let _ = newEntryViewController.view

    // Stubbing the view controllers
    factory.stub(diaryListWith: diaryListViewController)
    factory.stub(newEntryWith: newEntryViewController)
}

Great, we have a failing test again! Let's add a basic dairy list view controller and update our mocked factory in the test target to support it first.

typealias AddNewEntryCallback = () -> Void

class DiaryListViewController: UIViewController {

    fileprivate let addNewEntryCallback: AddNewEntryCallback

    init(addNewEntryCallback: @escaping AddNewEntryCallback) {
        self.addNewEntryCallback = addNewEntryCallback

        super.init(nibName: String(describing: DiaryListViewController.self), bundle: nil)
    }

    required init?(coder: NSCoder) {
        print("init(coder:) has not been implemented")
        return nil
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        navigationItem.rightBarButtonItem = UIBarButtonItem(barButtonSystemItem: .add, target: self, action: #selector(addButtonTapped(_:)))
    }

    @objc func addButtonTapped(_ sender: Any) {
        addNewEntryCallback()
    }
}

protocol ViewControllerFactory {

    var dataSource: DiaryDataSource { get }

    func diaryListViewController(router: DiaryRouter) -> DiaryListViewController
    func newEntryViewController(router: DiaryRouter) -> UIViewController
}

class MockViewControllerFactory: ViewControllerFactory {
    let dataSource: DiaryDataSource

    init(dataSource: DiaryDataSource) {
        self.dataSource = dataSource
    }

    fileprivate var stubbedDiary: DiaryListViewController? = nil
    fileprivate var stubbedNewEntry: UIViewController? = nil

    func stub(diaryListWith viewController: DiaryListViewController) {
        stubbedDiary = viewController
    }

    func stub(newEntryWith viewController: UIViewController) {
        stubbedNewEntry = viewController
    }

    func diaryListViewController(router: DiaryRouter) -> DiaryListViewController {
        guard let stubbedDiary = stubbedDiary else {
            fatalError("View controllers need to be stubbed for the tests")
        }
        return stubbedDiary
    }

    func newEntryViewController(router: DiaryRouter) -> UIViewController {
        return UIViewController()
    }
}

Also, change the list's test property in the base test case.

lazy var diaryListViewController: DiaryListViewController = {
    DiaryListViewController {}
}()

Our test still fails, but the errors are gone now. Now we need to connect the router to actually navigate to the entry screen. Let's add the following to the DiaryRouter.

func displayNewEntry() {
    let controller = factory.newEntryViewController(router: self)
    navigationController.pushViewController(controller, animated: true)
}

Perfect, our test succeeds now. I think at this point you get the idea of how the "red-green-refactor" process works in detail. From now on the post will only discuss the follow-up steps on a higher-level.

Don't forget, the whole demo project with all test cases is available on Github.

The next step is to test if the router can navigate to the entry screen of a selected entry.

func test_displaysEntryDetailsController() {
    router.displayDiaryList()
    router.displayEntryDetail(for: testEntry1)

    XCTAssertEqual(navigationController.viewControllers.count, 2)
    XCTAssertEqual(navigationController.viewControllers.first, diaryListViewController)
    XCTAssertEqual(navigationController.viewControllers.last, entryDetailViewController1)
}

func test_displaysDiaryListController_afterEntryDetail() {
    router.displayDiaryList()
    router.displayEntryDetail(for: testEntry1)
    router.displayDiaryList()

    XCTAssertEqual(navigationController.viewControllers.count, 1)
    XCTAssertEqual(navigationController.viewControllers.first, diaryListViewController)
}

func test_displaysEntryDetailsController_onlyOne() {
    router.displayDiaryList()
    router.displayEntryDetail(for: testEntry1)
    router.displayEntryDetail(for: testEntry2)

    XCTAssertEqual(navigationController.viewControllers.count, 2)
    XCTAssertEqual(navigationController.viewControllers.first, diaryListViewController)
    XCTAssertEqual(navigationController.viewControllers.last, entryDetailViewController2)
}

After extending our router to support this, we'll get something like this.

final class DiaryRouter: DiaryRouting {

    fileprivate let navigationController: UINavigationController
    fileprivate let factory: ViewControllerFactory

    init(navigationController: UINavigationController, factory: ViewControllerFactory) {
        self.navigationController = navigationController
        self.factory = factory
    }

    func displayDiaryList() {
        let controller = factory.diaryListViewController(router: self)
        navigationController.viewControllers = [controller]
    }

    func displayNewEntry() {
        resetToDiaryList()

        let controller = factory.newEntryViewController(router: self)
        navigationController.pushViewController(controller, animated: true)
    }

    func displayEntryDetail(for entry: Entry) {
        resetToDiaryList()

        let controller = factory.entryDetailViewController(entry: entry, router: self)
        navigationController.pushViewController(controller, animated: true)
    }

    // MARK: Helpers

    fileprivate func resetToDiaryList() {
        if navigationController.viewControllers.count != 1 { displayDiaryList() }
    }
}

And our factory's interface looks like the following. I've also added some documentation so future developers will understand immediately what it does.

protocol ViewControllerFactory {

    /// In our example the factory is the source of the data
    var dataSource: DiaryDataSource { get }

    /// Creates an entry list view controller
    /// - Parameters:
    ///   - router: Passed reference to the router
    func diaryListViewController(router: DiaryRouter) -> DiaryListViewController

    /// Creates a new entry view controller
    /// - Parameter router: Passed reference to the router
    func newEntryViewController(router: DiaryRouter) -> EntryDetailViewController

    /// Creates an entry detail view controller with the given entry
    /// - Parameters:
    ///   - router: Passed reference to the router
    func entryDetailViewController(entry: Entry,
                                   router: DiaryRouter) -> EntryDetailViewController
}

3. Testing the UI: diary list screen

It's always challenging to test the UI from code. When you initiate a view controller, it's important to force-load its view if you want to test actual views being rendered. The easist way is to do it like this. SUT stands for subject under testing.

fileprivate func makeSUT(entries: [Entry],
                          entrySelectionCallback: @escaping EntrySelectionCallback = { _ in },
                          entryRemovalCallback: @escaping EntrySelectionCallback = { _ in }) -> DiaryListViewController {

    let controller = DiaryListViewController(entries: entries,
                                              entrySelectionCallback: entrySelectionCallback,
                                              entryRemovalCallback: entryRemovalCallback,
                                              addNewEntryCallback: {})
    let _ = controller.view
    return controller
}

The first step is to add the easier tests for checking titles, init methods and so on.

func test_required_initWithCoder() {
    XCTAssertNil(DiaryListViewController(coder: NSCoder()))
}

func test_viewDidLoad_rendersTitle() {
    XCTAssertEqual(makeSUT(entries: []).title, "Diary")
}

Then we can test if the entry list table view gets rendered correctly. Please find the helper extensions for the table view in the source code on Github.

func test_viewDidLoad_rendersEntries() {
    XCTAssertEqual(makeSUT(entries: []).entryList.numberOfRows(inSection: 0), 0)
    XCTAssertEqual(makeSUT(entries: [testEntry1]).entryList.numberOfRows(inSection: 0), 1)
    XCTAssertEqual(makeSUT(entries: [testEntry1, testEntry2]).entryList.numberOfRows(inSection: 0), 2)
}

func test_viewDidLoad_rendersEntryTexts() {
    XCTAssertEqual(makeSUT(entries: [testEntry1]).entryList.title(at: 0), testEntry1.text.truncate(length: 80))
    XCTAssertEqual(makeSUT(entries: [testEntry1, testEntry2]).entryList.title(at: 1), testEntry2.text.truncate(length: 80))
}

Lastly, we need to check if the passed callbacks get called at the right time.

func test_entrySelection_callsEntrySelectedCallback() {
    var selectedEntry: Entry? = nil
    let sut = makeSUT(entries: [testEntry1], entrySelectionCallback: { entry in
        selectedEntry = entry
    })

    sut.entryList.select(row: 0)
    XCTAssertEqual(selectedEntry, testEntry1)
}

func test_entryRemoval_callsEntryRemovalCallback() {
    var selectedEntry: Entry? = nil
    let sut = makeSUT(entries: [testEntry1], entryRemovalCallback: { entry in
        selectedEntry = entry
    })

    sut.entryList.remove(row: 0)
    XCTAssertEqual(selectedEntry, testEntry1)
}

The minimum supporting code, that makes all tests pass is not that long at the end.

import UIKit

typealias EntrySelectionCallback = (Entry) -> Void
typealias AddNewEntryCallback = () -> Void

class DiaryListViewController: UIViewController {

    fileprivate(set) var entries: [Entry]
    fileprivate let entrySelectionCallback: EntrySelectionCallback
    fileprivate let entryRemovalCallback: EntrySelectionCallback
    fileprivate let addNewEntryCallback: AddNewEntryCallback

    @IBOutlet weak var entryList: UITableView!
    fileprivate let reuseIdentifier = "Cell"

    init(entries: [Entry],
         entrySelectionCallback: @escaping EntrySelectionCallback,
         entryRemovalCallback: @escaping EntrySelectionCallback,
         addNewEntryCallback: @escaping AddNewEntryCallback) {

        self.entries = entries
        self.entrySelectionCallback = entrySelectionCallback
        self.entryRemovalCallback = entryRemovalCallback
        self.addNewEntryCallback = addNewEntryCallback

        super.init(nibName: String(describing: DiaryListViewController.self), bundle: nil)
    }

    required init?(coder: NSCoder) {
        print("init(coder:) has not been implemented")
        return nil
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        setupNavigationBar()
        setupEntryList()
    }
}

// MARK: Navigation bar

extension DiaryListViewController {

    fileprivate func setupNavigationBar() {
        title = "Diary"
        navigationItem.rightBarButtonItem = UIBarButtonItem(barButtonSystemItem: .add, target: self, action: #selector(addButtonTapped(_:)))
    }

    @objc func addButtonTapped(_ sender: Any) {
        addNewEntryCallback()
    }
}

// MARK: Entry list

extension DiaryListViewController: UITableViewDelegate, UITableViewDataSource {

    fileprivate func setupEntryList() {
        entryList.register(UITableViewCell.self, forCellReuseIdentifier: reuseIdentifier)
    }

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

    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = UITableViewCell(style: .subtitle, reuseIdentifier: reuseIdentifier)
        let entry = entries[indexPath.row]

        cell.textLabel?.text = entry.text.truncate(length: 80)
        cell.textLabel?.lineBreakMode = .byWordWrapping
        cell.textLabel?.numberOfLines = 0
        cell.detailTextLabel?.text = entry.date.dateString()

        return cell
    }

    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        entryList.deselectRow(at: indexPath, animated: true)
        entrySelectionCallback(entries[indexPath.row])
    }

    func tableView(_ tableView: UITableView, commit editingStyle: UITableViewCell.EditingStyle, forRowAt indexPath: IndexPath) {
        if editingStyle == .delete {
            entryRemovalCallback(entries[indexPath.row])
        }
    }
}

4. Testing the UI: entry detail screen

The approach is very similar. First, let's test the init methods and the navigation bar.

func test_required_initWithCoder() {
    XCTAssertNil(EntryDetailViewController(coder: NSCoder()))
}

func test_viewDidLoad_rendersTitle() {
    XCTAssertEqual(makeSUT().title, Date().dateString())
    XCTAssertEqual(makeSUT(entry: testEntry1).title, testEntry1.date.dateString())
}

func test_viewDidLoad_rendersSaveButton() {
    XCTAssertEqual(makeSUT().navigationItem.rightBarButtonItem?.title, "Save")
    XCTAssertEqual(makeSUT(entry: testEntry1).navigationItem.rightBarButtonItem?.title, "Update")
}

Then let's test the content, which in this case is a text view.

func test_viewDidLoad_insertMode_rendersEmptyTextView() {
    XCTAssertEqual(makeSUT().textView.text, "")
}

func test_viewDidLoad_editMode_rendersFilledTextView() {
    XCTAssertEqual(makeSUT(entry: testEntry1).textView.text, testEntry1.text)
}

func test_saveButton_isEnabledIsControlledByTextView() {
    let sut = makeSUT()

    sut.textView.text = ""
    sut.textViewDidChange(sut.textView)
    XCTAssertFalse(sut.navigationItem.rightBarButtonItem!.isEnabled)

    sut.textView.text = testEntry1.text
    sut.textViewDidChange(sut.textView)
    XCTAssertTrue(sut.navigationItem.rightBarButtonItem!.isEnabled)
}

Lastly, let's test if the callback gets called properly.

func test_saveButton_savesEntryCorrectly() {
    var savedEntry: Entry? = nil
    makeSUT(entry: testEntry1, saveEntryCallback: { savedEntry = $0 }).navigationItem.rightBarButtonItem?.simulateTap()
    XCTAssertEqual(savedEntry, testEntry1)
}

Again, checking the minimum needed supporting code will give you a good feeling.

typealias SaveEntryCallback = (Entry) -> Void

class EntryDetailViewController: UIViewController {

    fileprivate(set) var entry: Entry?
    fileprivate let saveEntryCallback: SaveEntryCallback

    @IBOutlet weak var textView: UITextView!

    init(entry: Entry?,
         saveEntryCallback: @escaping SaveEntryCallback) {

        self.entry = entry
        self.saveEntryCallback = saveEntryCallback
        super.init(nibName: String(describing: EntryDetailViewController.self), bundle: nil)
    }

    required init?(coder: NSCoder) {
        print("init(coder:) has not been implemented")
        return nil
    }

    override func viewDidLoad() {
        super.viewDidLoad()

        setupTextView()
        setupNavigationBar()
    }

    fileprivate lazy var saveButton: UIBarButtonItem = {
        UIBarButtonItem(title: nil, style: .done, target: self, action: #selector(saveButtonTapped))
    }()
}

// MARK: Navigation bar

extension EntryDetailViewController {

    fileprivate func setupNavigationBar() {
        title = (entry?.date ?? Date()).dateString()
        navigationItem.rightBarButtonItem = saveButton
        updateNavigationBar()
    }

    @objc func saveButtonTapped(_ sender: Any) {
        saveEntryCallback(Entry(date: entry?.date ?? Date(), text: textView.text))
        navigationController?.popViewController(animated: true)
    }

    fileprivate func updateNavigationBar() {
        saveButton.title = entry != nil ? "Update" : "Save"
        navigationItem.rightBarButtonItem?.isEnabled = !textView.text.isEmpty
    }
}

// MARK: Text view

extension EntryDetailViewController: UITextViewDelegate {

    fileprivate func setupTextView() {
        textView.text = entry?.text
        textView.becomeFirstResponder()
    }

    func textViewDidChange(_ textView: UITextView) {
        updateNavigationBar()
    }
}

5. Testing the factory

When we test the factory, we're basically only curious if the view controllers are being created the way we expect them to be.

func test_diaryList_rendersControllerWithValidEntries() {
    XCTAssertEqual(makeDiaryListController().entries.count, 0)
    dataSource.save(entry: testEntry1)
    XCTAssertEqual(makeDiaryListController().entries.count, 1)
}

func test_newEntry_rendersWithEmptyEntry() {
    XCTAssertNil(makeNewEntryController().entry)
}

func test_newEntry_rendersWithEntry() {
    XCTAssertEqual(makeEntryDetailController(entry: testEntry1).entry, testEntry1)
}

6. Testing the flows

Testing complete flows is a bit trickier. Actually, in our case this comes from the lazy architecture design for the demo project. Since the factory is the source of truth in the application, these tests are basically end-to-end tests and cover a whole flow.

For example, this one tests if saving a new entry on the new entry screen actually creates a new entry in the data source and navigates back to the list.

func test_savingNewEntry() {
    let controller = makeNewEntryController()
    controller.textView.text = testText1
    controller.textViewDidChange(controller.textView)
    controller.navigationItem.rightBarButtonItem?.simulateTap()

    XCTAssertEqual(dataSource.sortedEntries.count, 1)
    XCTAssertEqual(navigationController.viewControllers.count, 1)
    guard let _ = navigationController.viewControllers[0] as? DiaryListViewController else {
        return XCTFail("Diary list screen hasn't been created after saving an entry")
    }
}

Similarily, this one tests if removing an entry from the list will reset the navigation stack to a new list with the updated data source.

func test_removingAnEntry() {
    dataSource.save(entry: testEntry1)
    dataSource.save(entry: testEntry2)
    dataSource.save(entry: testEntry3)

    let controller = makeDiaryListController()
    XCTAssertEqual(controller.entryList.numberOfRows(inSection: 0), 3)
    controller.entryList.remove(row: 1)

    // A new list is created and added as the root view controller at this point
    guard let newController = navigationController.viewControllers[0] as? DiaryListViewController else {
        return XCTFail("New list hasn't been created after removing an entry")
    }

    let _ = newController.view
    XCTAssertEqual(newController.entryList.numberOfRows(inSection: 0), 2)
    XCTAssertEqual(dataSource.sortedEntries.count, 2)
}

The last two are quite self-explanatory. They check if the app routes to the proper screen based on the matching user action.

func test_startingAddingNewEntries() {
    let controller = makeDiaryListController()
    XCTAssertEqual(controller.entryList.numberOfRows(inSection: 0), 0)
    controller.navigationItem.rightBarButtonItem?.simulateTap()

    XCTAssertEqual(navigationController.viewControllers.count, 2)
    guard let _ = navigationController.viewControllers[1] as? EntryDetailViewController else {
        return XCTFail("Entry detail screen hasn't been created after tapping on the add button")
    }
}

func test_entrySelection() {
    dataSource.save(entry: testEntry1)
    dataSource.save(entry: testEntry2)

    let controller = makeDiaryListController()
    XCTAssertEqual(controller.entryList.numberOfRows(inSection: 0), 2)
    controller.entryList.select(row: 1)

    XCTAssertEqual(navigationController.viewControllers.count, 2)
    guard let _ = navigationController.viewControllers[1] as? EntryDetailViewController else {
        return XCTFail("Entry detail screen hasn't been created after selecting an entry")
    }
}

App architecture

Let's review quickly our app structure. We implemented the following main modules:

App
The application's main module. Creates a data source, a router, and a factory instance, then displays the diary list with the router.
UI
Plain UIViewControllers, that display the entry list and the entry details and forwards potential callbacks (removing and adding entries).
Data
The entry data model, the interface description and the implementation of the data source.
Routing
The interface of how a view controller factory should behave, the interface and the implementation of our router.

If we take a look back to our concept, that's very similar to what we wanted. Of course, this setup only serves demo purposes, a production-ready app's architecture would look more sophisticated.

Summary

Even though our demo architecture was not optimal, with being test-driven we could reach 100% coverage. In case we'd need to extend our app with new features, it's highly likely we'd catch all potential bugs on time.

All in all, applying TDD is really interesting and fun. It somehow reverses how a developer thinks about implementing an app. My personal main takeaways are that UI comes last and that I should only implement what I actually need. Thanks a lot for reading!

The source code for the article is available on Github.