Swift Test: управление поведением клиента mo c api

Question

Я пишу тест для своего проекта и объявил удаленный API-клиент protolcol:

public protocol ApiClient {
    func load(completion: @escaping ([Any]?, String?))
}

и определил клиент API mo c, который подтверждает ApiClient:

class MocApiClient: ApiClient {
    func loadFlights(completion: @escaping ([Any]?, String?)) {
        // Load a sample JSON file and return it as response
    }
}

таким образом я могу вернуть ответ, загрузив файл JSON. Это счастливый путь теста. После этого я начал думать о тестировании различных возможных типов ответов и решил, что смогу изменить поведение MocApiClient, и определил это:

enum TestPath {
    case success
    case failure
}

и использую его с MocApiClient:

class MocApiClient: ApiClient {

    var path: TestPath = .success

    func load(completion: @escaping ([Any]?, String?) -> Void) {

        switch path {
        case .success:
            completion([...], nil)
        case .failure:
            completion(nil, "error message")
        }
    }
}

Думаешь, это хорошее решение? Есть ли у вас какие-нибудь подходы к пиву?

Answer 1

Ваш подход выглядит хорошо, если у вас есть всего несколько простых тестов. Однако, если у вас относительно сложная логика c и вам необходимо протестировать множество положительных и отрицательных путей, альтернативой вашему решению будет создание нескольких различных объектов-насмешек, каждый из которых имеет одну цель.

Таким образом вы избежите серьезной универсальной проблемы с поддельными объектами, а также сможете определять свои объекты-заглушки прямо в методах тестов, которые их используют, что делает ваши тесты еще более сфокусированными и независимыми.

Что-то вроде это:

func testSuccessfulResponse() {
    class MockApiClientSuccessfulResponse: ApiClient {
        ...
    }
    ...
}

func testMalformedResponse() {
    class MockApiClientMalformedResponse: ApiClient {
        ...
    }
    ...
}

func testInconsistentData() {
    class MockApiClientInconsistentData: ApiClient {
        ...
    }
    ...
}

Надеюсь, это поможет и удачного юнит-тестирования!