DEV Community: Oren Idan Yaari

Testable Apps: Why You Should Consider The Composable Architecture

Oren Idan Yaari — Sat, 04 May 2024 08:26:26 +0000

Recently, I've been seeing some discussion around whether integrating TCA into our app is necessary. I wanted to take a moment to address that here.

So, why should we consider using The Composable Architecture (TCA)? Well, it's been purpose-built with testing in mind right from the start. If you're working with SwiftUI, it offers a seamless way to incorporate test coverage into your codebase. Plus, it empowers us to simulate complex user flows effortlessly. Imagine seamlessly changing a state deep within a screen and then validating that state change in its parent screen – TCA makes tasks like these a breeze.

But I get it, some might wonder if the benefits outweigh the added complexity of integrating an external library. Let's explore that with an example.

Imagine we're developing a new feature. Following Apple's recommendation to use Swift and SwiftUI, we start building our feature.

We create a simple ViewModel to manage some state:

class ViewModel: ObservableObject {
    struct State {
        var iLikeTest = false
    }
    @Published var state = State()

    func someFunction() {
        state.iLikeTest = true
    }
}

Now, let's say we want to test whether a specific action changes the state correctly:

class BlogCodeTests: XCTestCase {
    func testSomething() {
        let sut = ViewModel()
        sut.$state.sink { newState in
            XCTAssertFalse(newState.iLikeTest)
        }
        sut.someFunction()
    }
}

This approach works, but it's not without its drawbacks. For instance, when Apple introduces a new observation macro in iOS 17 for performance enhancements, our tests break because we've removed Combine and @Published. Now there is no way to observe the state outside a SwiftUI View.

@Observable
class ViewModel {
    struct State {
        var iLikeTest = false
    }
    var state = State()

    func someFunction() {
        state.iLikeTest = true
    }
}

To fix this, we need to refactor our tests to use a global observation function. It's a cumbersome solution and can make certain flows untestable.

func testSomething() {
        let exp = expectation(description: "fulfill onChange")
        let sut = ViewModel()
        withObservationTracking {
            sut.state.iLikeTest
        } onChange: {
            XCTAssertTrue(sut.state.iLikeTest)
            exp.fulfill()
        }
        sut.someFunction()
        waitForExpectations(timeout: 1)
    }

This doesn't really work. The test will fail because onChange will still show the value to be false. We might be able to find a way around it, but this is where TCA comes into action. Let's take a look at how we could implement the same functionality with TCA:

@Reducer
struct MainStore {
    @ObservableState
    struct State: Equatable {
        var iLikeTest = false
    }

    enum Action {
        case someAction
    }

    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .someAction:
                state.iLikeTest = true
                return .none
            }
        }
    }
}

And now, our test becomes much simpler and more robust:

func testReducer() async {
    let testStore = TestStore(initialState: .init()) {
        MainStore()
    }

    await testStore.send(.someAction) {
        $0.iLikeTest = true
    }
}

No need to overthink it. Just call an action on a store, change to the expected state, and voila! If we don't change the state, we get a failure. If we forget to override a dependency, we get a failure. What's even better that it is all built on top of Apple's observable macros.
So, before making a decision, I'd encourage you to delve deeper into TCA and compare it against the vanilla SwiftUI approach.

Simplifying Test Writing with Protocol Witnesses in Swift

Oren Idan Yaari — Tue, 20 Feb 2024 06:41:22 +0000

In my previous post, we explored writing testable code and methods to enhance our test-writing skills. This article introduces a technique that significantly simplifies the process of writing tests, resulting in less redundancy and more maintainable tests.

Let's start with a fundamental need of every app - data. Here, we'll introduce our first two protocols to abstract the database and the network. Protocols traditionally serve as our go-to strategy for isolating and managing dependencies, enabling us to alter and mock behaviors during tests. We'll also include another analytics protocol, just for fun:

class ViewModel {
    // Protocols
    let networkClient: NetworkClientProtocol
    let dbClient: DBClientProtocol
    let analyticsClient: AnalyticsClientProtocol

    @Published var movies: [Movie] = []
    @Published var error: Error?

    init(
        networkClient: NetworkClientProtocol = NetworkClient(),
        dbClient: DBClientProtocol = DBClient(),
        analyticsClient: AnalyticsClientProtocol
    ) {
        self.networkClient = networkClient
        self.dbClient = dbClient
        self.analyticsClient = analyticsClient
    }

    // Fetch the data when the view appears
    func onAppear() async {
        do {
            movies = dbClient.fetchMovies()
            if movies.isEmpty {
                let url = URL(string: "https://getmovies.com")!
                movies = try await networkClient.fetchData(for: url)
            }
            analyticsClient.log(event: "fetched_movies")
        } catch {
            self.error = error
            analyticsClient.log(event: "fetched_movies_failed")
        }
    }
}

When the view loads, we check the database for existing movies. If not found, we proceed to retrieve the data directly from the server.
Next, we set out to design our tests to ensure the "happy path" operates as expected, fetching movies from a simulated network and populating the error if any exception arises:

  final class BlogCodeTests: XCTestCase {
    func testOnAppear_HappyPath() async {
        let analytics = FakeAnalytics()

        let sut = ViewModel(
            networkClient: HappyNetworkClient(),
            dbClient: FakeDBClient(),
            analyticsClient: analytics
        )

        await sut.onAppear()
        XCTAssertEqual(sut.movies, [Movie(id: 1, title: "The Karate Kid")])
        XCTAssertEqual(analytics.eventTracker, "fetched_movies")
    }

    func testOnAppear_Failure() async {
        let analytics = FakeAnalytics()

        let sut = ViewModel(
            networkClient: FailingNetworkClient(),
            dbClient: FakeDBClient(),
            analyticsClient: analytics
        )

        await sut.onAppear()
        XCTAssertNotNil(sut.error)
        XCTAssertEqual(analytics.eventTracker, "fetched_movies_failed")
    }

    enum MockError: Error {
        case testError
    }

    class FailingNetworkClient: NetworkClientProtocol {
        func fetchData<T: Codable>(for url: URL) async throws -> T {
            throw MockError.testError
        }
    }

    class HappyNetworkClient: NetworkClientProtocol {
        static var movie = Movie(id: 1, title: "The Karate Kid")

        func fetchData<T: Codable>(for url: URL) async throws -> T {
            return [Self.movie] as! T
        }
    }

    class FakeDBClient: DBClientProtocol {
        func fetchMovies() -> [BlogCode.Movie] {
            []
        }
    }

    class FakeAnalytics: AnalyticsClientProtocol {
        var eventTracker: String?

        func log(event: String) {
            eventTracker = event
        }
    }
}

Having introduced mock network and database clients, we've enabled testing paths, allowing us to simulate success and failure. Yet, it feels like we are drowning in protocols and we haven't even tested all the cases. Could there be a way to streamline dependency management without protocols?

Enter Protocol Witnesses, a concept I first encountered through the excellent Point Free videos, I highly recommend them.
The idea behind Protocol Witnesses boils down to this: Instead of a protocol, we use a value type with function fields. Simple, right? This means that what was previously a function signature in a protocol now becomes a lambda within a struct.
However, it's important to remember that Protocol Witnesses are another tool in our tool-belt; there's still a place for protocols in our code. Both approaches have their unique strengths and applications, providing us with a more versatile set of options for tackling different coding challenges. Embracing Protocol Witnesses doesn't mean abandoning protocols altogether but rather enriching our toolkit with more ways to write efficient, maintainable, and clean code.
Now, let's dive into how the Movies app undergoes a transformation with Protocol Witnesses:

struct Dependencies {
    // Transform the protocol signature into functions
    var getMovies: () async throws -> [Movie]
    var logEvent: (String) -> Void

    // The live implementation to use in production
    static func live() -> Self {
        let dbClient = DBClient()
        let networkClient = NetworkClient()

        return Self {
            let movies = dbClient.fetchMovies()
            if movies.isEmpty {
                return try await networkClient.fetchData(for: url)
            }
            return movies
        } logEvent: { event in
            // Call the live analytics client
            print(event)
        }
    }
}

class ViewModel {
    let dependencies: Dependencies

    @Published var movies: [Movie] = []
    @Published var error: Error?

    // Use the live implementation as a default
    init(dependencies: Dependencies = .live()) {
        self.dependencies = dependencies
    }

    func onAppear() async {
        do {
            movies = try await dependencies.getMovies()
            dependencies.logEvent("fetched_movies")
        } catch {
            self.error = error
            dependencies.logEvent("fetched_movies_failed")
        }
    }
}

With just a few tweaks, we've eliminated the need for protocols altogether. In our production environment, we now rely on live functions for fetching movies and analytics, freeing us from the constraints of protocol adherence.

And here comes the real game changer: let's drastically reduce the boilerplate code associated with protocols in our testing setup:

func testOnAppear_HappyPath() async {
        let expectation = XCTestExpectation(description: "analytics call")

        // Override the dependencies functions right where they are in use
        let sut = ViewModel(
            dependencies: Dependencies  {
                [Movie(id: 1, title: "The Karate Kid")]
            } logEvent: { event in
                XCTAssertEqual(event, "fetched_movies")
                expectation.fulfill()
            }
        )

        await sut.onAppear()
        XCTAssertEqual(sut.movies, [Movie(id: 1, title: "The Karate Kid")])
        await fulfillment(of: [expectation])
    }

    func testOnAppear_Failure() async {
        let expectation = XCTestExpectation(description: "analytics call")

        let sut = ViewModel(
            dependencies: Dependencies  {
                throw MockError.testError
            } logEvent: { event in
                XCTAssertEqual(event, "fetched_movies_failed")
                expectation.fulfill()
            }
        )

        await sut.onAppear()
        XCTAssertNotNil(sut.error)
        await fulfillment(of: [expectation])
    }

We have removed about 30 lines of protocol code allowing us to streamline the testing process and make it more manageable. Using value types instead of protocols significantly reduces the amount of code required and enables us to override data in place without needing additional protocol conformances.
This is just the beginning of what Protocol Witnesses enable us to achieve. Once again, I highly recommend exploring Point Free and their innovative approach, especially their library for dependency injection.

Building Testable Habits

Oren Idan Yaari — Sun, 04 Feb 2024 09:36:15 +0000

Introduction:

When I embarked on my coding journey, Objective-C reigned supreme, and the MVC (Massive View Controller) pattern was our foundation. It began smoothly, but as our project's ambitions grew, so did the codebase's complexity. Before we knew it, our once-smooth-sailing ship started showing signs of strain. Code changes became treacherous minefields of regressions, and bugs transformed from minor annoyances into significant roadblocks.

For the next project, our team embraced Swift and the MVVM pattern, which had gained popularity at the time. We also committed to covering every view model with unit tests. Unit testing offered us three essential benefits:

Guaranteed Expected Behavior: Ensured the code functioned as intended.
Confident Code Changes: Enabled confident code modifications, knowing tests would catch simple mistakes. It provides a safety net and helps identify potential issues.
Clear Documentation: Served as clear documentation of how the system under test (SUT), in this case the view model, should operate.

Our biggest hurdle was getting started. As a small team of three developers, none of us had prior experience with unit testing. I took it upon myself to research and share my findings with the team, which is what I'm doing in this blog post.

Writing Testable Code:

The first and most crucial step is writing testable code. While this may seem challenging, we can break it down into two key questions: what constitutes testable code, and how can we hone this skill?

To illustrate what constitutes testable code, consider a Movie list app with a view model responsible for fetching data and populating a movie array. The specifics of the technology or UI framework matter less than the principle of testability.

First, we need a simple data fetching mechanism:

class NetworkClient {
    static var shared = NetworkClient()

    private init() {}

    func fetchData<T: Codable>(for url: URL) async throws -> T {
        let (jsonData, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode(T.self, from: jsonData)
    }
}

Next, a straightforward view model, kept as simple as possible to focus on testing:

@Observable
class ViewModel {
    var movies = [Movie]()

    func onAppear() {
        Task { [weak self] in
            let url = URL(string: "https://getmovies.com")!
            do {
                self?.movies = try await NetworkClient.shared.fetchData(for: url)
            } catch {
                print(error)
            }
        }
    }
}

Now we need to test the ViewModel, but we encounter an initial challenge: the network client is implemented as a singleton, rendering it unreplaceable within our tests. Unit tests should prioritize speed and self-containment. Reliance on external servers is undesirable, as it introduces potential unavailability and the risk of overwhelming them with excessive requests.

Fortunately, Dependency Injection (DI) emerges as a potent solution. By injecting the NetworkClient, we gain control over it within our testing environment, effectively isolating the ViewModel from network interactions. Furthermore, to provide the unit test with comparative data, we employ mock data. This necessitates the creation of a protocol for NetworkClient, empowering us to specify the mock data we require.

protocol NetworkClientProtocol {
    func fetchData<T: Codable>(for url: URL) async throws -> T
}

class NetworkClient: NetworkClientProtocol {
    func fetchData<T: Codable>(for url: URL) async throws -> T {
        let (jsonData, _) = try await URLSession.shared.data(from: url)
        return try JSONDecoder().decode(T.self, from: jsonData)
    }
}

@Observable
class ViewModel {
    let networkClient: NetworkClientProtocol
    var movies = [Movie]()

    init(networkClient: NetworkClientProtocol = NetworkClient()) {
        self.networkClient = networkClient
    }

    func onAppear() {
        Task {
            let url = URL(string: "https://getmovies.com")!
            do {
                self.movies = try await self.networkClient.fetchData(for: url)
            } catch {
                print(error)
            }
        }
    }
}

With the foundation of DI and mock data in place, we can proceed to construct our first test case. The objective is to verify that the onAppear function, when invoked, successfully populates the Movies list with the expected data.

func testOnAppear() {
        let sut = ViewModel(networkClient: FakeNetworkClient())
        sut.onAppear()
        XCTAssertEqual(sut.movies, [FakeNetworkClient.movie])
    }

    class FakeNetworkClient: NetworkClientProtocol {
        static var movie = Movie(id: 1, title: "The Karate Kid")

        func fetchData<T: Codable>(for url: URL) async throws -> T {
            return [Self.movie] as! T
        }
    }

We’ve injected the fake network client with the mock data, but despite our efforts, the test still fails. The Movies list remains empty during the assertion. If we run the app, it looks like everything is working correctly. So why doesn’t it work? The answer is - asynchronous operations and their impact on test execution.
The Task within onAppear triggers a context switch, meaning the execution flow temporarily shifts away from the test's primary thread. As a result, the assertion executes before the fetchData call completes, leading to an empty list and a failed test. Delaying the assertion with sleep or using expectations with timeouts can address this issue. However, these approaches introduce uncertainty and potential slowness, compromising test speed and reliability. And always remember - the fact that it works on your local machine does not guarantee it will work on the CI (Continuous Integration) machine!
Swift's async capabilities offer a more elegant solution. By declaring onAppear as async and shifting the Task initiation to the View layer, we can:

Ensure Sequential Execution: The test code and onAppear function execute sequentially within the same context, eliminating premature assertions.
Preserve Test Speed: The test avoids unnecessary delays or timeouts, maintaining its swiftness and efficiency.

Here is the new implementation:

func onAppear() async {
        let url = URL(string: "https://getmovies.com")!
        do {
            self.movies = try await self.networkClient.fetchData(for: url)
        } catch {
            print(error)
        }
    }

func testOnAppear() async {
        let sut = ViewModel(networkClient: FakeNetworkClient())
        await sut.onAppear()
        XCTAssertEqual(sut.movies, [FakeNetworkClient.movie])
    }

Improving Test Writing Skills:

Having successfully navigated the initial challenges of testing asynchronous operations in our Movies app, we've gained valuable insights into writing testable code. Now, we turn our attention to the second crucial question: how can we continuously improve our testable code writing skills?

While the suggestion I'm about to offer may initially seem daunting, the most effective method I've encountered is Test-Driven Development (TDD). Now, before you flee in terror, allow me to reassure you: don't feel pressured to adopt TDD for everything; it's entirely your choice. Even simply understanding the principles of TDD can enhance your daily code structure.

The key aspect of TDD I want to suggest is engaging in “coding katas”. Think of them as specific coding challenges, similar to how karate katas train muscle memory for martial arts movements. By repeatedly practicing these challenges, you solidify testable code habits, naturally enhancing your skills. Each kata presents a unique problem you address multiple times, progressively improving your ability to write testable code.

The concept is straightforward, and you can delve deeper in the excellent Quality Coding site HERE by Jon Reid. As a starting point, I highly recommend the Bowling Game challenge. Dedicating just 15 minutes daily for a week, and you'll likely see a significant improvement in your testing skills by the end!

Over the years, I've interacted with many iOS developers working on codebases lacking test coverage, often unsure how to introduce it to their teams. If you find yourself in this situation, consider proposing Katas as a workshop. This allows your team to experience TDD firsthand in a collaborative setting, alleviating their concerns by emphasizing the learning aspect. Build upon this initial workshop experience as you move forward.

For teams with existing tests, incorporating Katas into the onboarding process for new developers can be immensely beneficial. Even those with limited testing experience can quickly gain proficiency through this practice.

The journey doesn't stop here! In the next post, we'll explore further strategies to enhance your testing flow. We'll eliminate the need for protocols to inject mocks in our dependencies and explore testing beyond the "happy path" scenario. Stay tuned!