sMock — Swift mocking framework для Unit-tests (спасибо gMock за идеи)

Проблема

Переходя в мир Swift из ObjC/C++, я столкнулся с проблемой при написании юнит-тестов: отсутствием инструментов для создания Mock-объектов.

При написании декомпозированного кода мы часто скрываем детали реализации за интерфейсами (протоколами). А также проверять функциональность того или иного объекта отдельно от других очень удобно, подменяя его составняе части моками.

Погуглив, я нашел несколько фреймворков Swift Mocking на github. Но ни один из них не явился мне ясным и очевидным в использовании (по одной или нескольким причинам):

• имеет тучу зависимостей
• не имеет интуитивного синтаксиса
• требуется кодогенерация / написание вручную большого количества вспомогательного кода
• не интегрирован с XCTest (позволяет мокать, но не тестировать)
• иметь много возможностей, сваленых в кучу одного фреймворка (неразбериха что и зачем)
• должен использоваться с ограниченным количеством предопределенных/встроенных типов

Эта ситуация была для меня неприятной, и напротяжении около года я использовал обходные пути и самописные моки.
Самописные Mock-объекты просты, но они

• каждый раз разные (изобретаем велосипед)
• или каждый раз одинаковые (копипаст)
• неочевидные в использовании

Решение

В мире C ++ существует популярный и чудесный фреймворк gTest / gMock (от Google).
Он позволяет создавать Mock-объекты очень наглядно и компактно. Также он имеет интуитивно понятный синтаксис, который позволяет просто «читать» (не изучать) написанный тестовый код.

Вдохновленный gMock, я решил написать фреймворк sMock (Swift Mock) с похожим подходом и синтаксисом gMock.
https://github.com/Alkenso/sMock

sMock:

• написание mock на протоколы/базовые классы и коллбеки
• интуитивно понятный синтаксис установки expectations
• минимально-требуемый код для создания mock-объектов
• интегрирован с XCTest.framework
• работает с любыми типами
• расширяемый
• поддерживает синхронные и асинхронные тесты
• zero-dependency
• pure Swift

Пример(ы)

Для тестирования с sMock нужно

• создать Mock класс, который имплементит методы протокола (переопределяем методы родителя)
• в Mock классе объявить вспомогательные проперти methodCall. "замокать" методы.

Mocking synchronous method

Начнём с наиболее простого случая: синхронный код

import XCTest
import sMock

//  Протокол для примера, который будем мокать
protocol HTTPClient {
    func sendRequestSync(_ request: String) -> String
}

//  Mock реализация
class MockHTTPClient: HTTPClient {
    //  Определяем call's mock entity.
    let sendRequestSyncCall = MockMethod<String, String>()

    func sendRequestSync(_ request: String) -> String {
        //  1. Пробрасываем агрументы в Mock-сущность
        //  2. Для non-void результата предоставляем "default" результат для случая 'Unexpected call' (т.е. когда мы вызова не ожидаем, но он произошёл).
        sendRequestSyncCall.call(request) ?? ""
    }
}

//  Объект, который мы хотим тестировать
struct Client {
    let httpClient: HTTPClient

    //  Клиент, используя HTTP транспорт, получает и парсит данные.
    func retrieveRecordsSync() -> [String] {
        let response = httpClient.sendRequestSync("{ action: 'retrieve_records' }")
        return response.split(separator: ";").map(String.init)
    }
}

class ExampleTests: XCTestCase {
    func test_Example() {
        let mock = MockHTTPClient()
        let client = Client(httpClient: mock)

        //  Далее мы пишем expectation, при котором метод 'sendRequestSync' у HTTPClient будет вызван с агрументом 'request' равным "{ action: 'retrieve_records' }".
        //  Мы ожидаем, что метод будет вызван только 1 раз и вернёт строку "r1;r2;r3".
        mock.sendRequestSyncCall
            //  Именуем наш expectation (полезно для чтения сообщений о ошибке теста);
            .expect("Request sent.")
            //  Говорим, что данное expectation подходит только для случая, когда аргумент соответствуем таковому в match
            .match("{ action: 'retrieve_records' }")
            //  Задаём количество раз, сколько мы ожидаем что будет вызван метод (для конкретно данного match)
            .willOnce(
                //  Указываем, что должен вернуть метод.
                .return("r1;r2;r3"))

        //  Установив expectations, вызываем метод Client-а и проверяем распаршенный результат.
        let records = client.retrieveRecordsSync()
        XCTAssertEqual(records, ["r1", "r2", "r3"])
    }
}

Mocking synchronous method + mocking asynchonous callback

Для второго примера хотел бы рассмотреть дополнительно кейс с написанием Mock callback'a, которым мы тестируем возвращаемый асинхронно результат.

//  Протокол для примера, который будем мокать
protocol HTTPClient {
    func sendRequestSync(_ request: String) -> String
}

//  Mock реализация
class MockHTTPClient: HTTPClient {
    //  Определяем call's mock entity.
    let sendRequestSyncCall = MockMethod<String, String>()

    func sendRequestSync(_ request: String) -> String {
        //  1. Пробрасываем агрументы в Mock-сущность
        //  2. Для non-void результата предоставляем "default" результат для случая 'Unexpected call' (т.е. когда мы вызова не ожидаем, но он произошёл).
        sendRequestSyncCall.call(request) ?? ""
    }
}

//  Объект, который мы хотим тестировать
struct Client {
    let httpClient: HTTPClient

    //  Клиент, используя HTTP транспорт, получает и парсит данные. Результат возвращает асинхронно
    func retrieveRecordsAsync(completion: @escaping ([String]) -> Void) {
        let response = httpClient.sendRequestSync("{ action: 'retrieve_records' }")
        completion(response.split(separator: ";").map(String.init))
    }
}

class ExampleTests: XCTestCase {
    func test_Example() {
        let mock = MockHTTPClient()
        let client = Client(httpClient: mock)

        //  Далее мы пишем expectation, при котором метод 'sendRequestSync' у HTTPClient будет вызван с агрументом 'request' равным "{ action: 'retrieve_records' }".
        //  Мы ожидаем, что метод будет вызван только 1 раз и вернёт строку "r1;r2;r3".
        mock.sendRequestSyncCall
            //  Именуем наш expectation (полезно для чтения сообщений о ошибке теста);
            .expect("Request sent.")
            //  Говорим, что данное expectation подходит только для случая, когда аргумент соответствуем таковому в match
            .match("{ action: 'retrieve_records' }")
            //  Задаём количество раз, сколько мы ожидаем что будет вызван метод (для конкретно данного match)
            .willOnce(
                //  Указываем, что должен вернуть метод.
                .return("r1;r2;r3"))

        //  Теперь создаём expectation для коллбека клиента (асинхронный ответ). 
        //  Мы должны быть уверенны, что по завершению теста колбек-таки был вызван: используем 'MockClosure' mock entity.
        //  Здесь мы установим expectation, что коллбек будет вызван строго 1 раз с результатом (распаршенным клиентом) ["r1", "r2", "r3"].
        let completionCall = MockClosure<[String], Void>()
        completionCall
            //  Именуем наш expectation (полезно для чтения сообщений о ошибке теста);
            .expect("Records retrieved.")
            //  Говорим, что данное expectation подходит только для случая, когда аргумент соответствуем таковому в match
            .match(["r1", "r2", "r3"])
            //  Задаём количество раз, сколько мы ожидаем что будет вызван метод (для конкретно данного match).
            //  Поскольку return value у коллбека Void, .return можем не писать.
            .willOnce()

        //  Установив expectations, вызываем метод Client-а.
        client.retrieveRecordsAsync(completion: completionCall.asClosure())

        //  Дожидаемся завершения всех установленных expectations (если вызовы "под капотом" выполняются на другом потоке).
        sMock.waitForExpectations()
    }
}

Matchers, Actions, Argument capture

sMock также предоставляем (см. доку на гитхаб):

• объемное семейство Matchers — вспомогательных классов, которые можно использовать в .match: от .any (любой агрумент) до анализа контента коллекций
• кастомные Actions: expectation может при match'e не только .return, но и полностью кастомизированный блок.
• захват агрументов: при вызове expectation захватывать агрументы в спец. объект
• кастомизацию конфигурации: таймаут ожидания, кастомное поведение при unexpectedCall

Итог

Наличие приятных в использовании инструментов тестирования позволяют разработчикам писать тесты с большим желанием.
Чистый код тестов делает их читабельными и поддерживаемыми.
Широко известно: человек будет использовать те инструменты, которые ему нравятся. В противном случае он будет всячески избегать их использования.

Я был приятно удивлён тем, что у Swift широкое и социальное сообщество.
Буду рад всем, кому sMock придётся по душе. Обязательно сообщайте об ошибках и предложениях.
Сообща можно создать действительно стоящий инструмент "testing with Swift"!

Try sMock on github (with SwiftPackageManager)