Как я могу сделать модульные тестовые случаи экрана входа в iOS Swift - PullRequest
0 голосов
/ 02 мая 2019

У меня проблема на экране входа.Как создать тестовый блок с экраном входа в систему?У меня есть экран имени пользователя и пароля с кнопкой действия.Мне нужно вызвать API при нажатии на кнопку и выполнить несколько тестов.Пожалуйста, предоставьте мне некоторую информацию.заранее спасибо.

Ответы [ 3 ]

1 голос
/ 03 мая 2019

Самый простой подход - структурировать ваш код так, чтобы он фактически не инициировал вызов API входа в систему.Вместо этого он:

  • Создает запрос, но останавливается перед его отправкой
  • Обрабатывает ответ

Затем вы можете проверить это заполнение полей инажатие на кнопку создает правильный запрос.После этого вы можете протестировать различные ответы, в том числе всевозможные случаи ошибок, которые трудно создать при сквозном тестировании.

Чтобы нажать кнопку из модульного теста, сделайте так, чтобы тест могполучить доступ к кнопке.Затем позвоните sendActions(for: .touchUpInside)

Подробнее читайте в ближайшее время… Модульное тестирование iOS на примере: советы и методики XCTest с использованием Swift


Пример: Есть много способовструктурировать это.Допустим, у нас есть протокол

protocol NetworkCalling {
    typealias CallResult = Result<(Data, URLResponse), Error>
    typealias CompletionHandler = (CallResult) -> Void

    func call(request: URLRequest, completionHandler: @escaping CompletionHandler)
}

Наш контроллер представления будет использовать все, что ему дают.Это не волнует.Он просто знает, как сделать URLRequest из своих свойств.Он также знает, как обрабатывать результат, как для успеха, так и для отказа.

class ViewController: UIViewController {
    var networkCall: NetworkCalling?

    @IBAction private func login(sender: AnyObject) {
        let request = URLRequest(url: URL(string: "http://foo.bar?baz")!)
        networkCall?.call(request: request) { [weak self] result in
            self?.handleResult(result)
        }
    }

    private func handleResult(_ result: NetworkCalling.CallResult) {
        switch result {
        case let .success(data, response):
            break
        case let .failure(error):
            break
        }
    }
}

Протокол вводит границу.Контроллер вида не может видеть за этой границей.Это не бизнес контроллера представления.Протокол дает нам возможность предоставлять различные реализации:

  • Что-то, что делает реальные сетевые вызовы.
  • Декоратор, который оборачивает другого реализатора, выполняя ведение журнала.
  • A TestШпион, который фиксирует свои аргументы для модульного тестирования.
  • Подделка, которая воспроизводит сохраненные ответы для тестирования пользовательского интерфейса.Это делает тестирование пользовательского интерфейса быстрее и надежнее.
0 голосов
/ 02 мая 2019

Хотя вопрос кажется довольно широким, позвольте мне упомянуть некоторые полезные моменты:

  • В модульном тесте мы заботимся о функциональности сцены, а не заботимся о визуальных компонентах пользовательского интерфейса, например. Итак, что вы говорите о тестировании на вход в систему:

Мне нужно вызвать API при нажатии на кнопку и сделать какой-то блок контрольные примеры.

действительно, это одна из основных функций в сцене.

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

  • Что касается вышеуказанного пункта, как его применять? Вы могли бы следовать подходу «издевательства» над ответом. Вкратце, то, что вы могли бы сделать, - это создать фиктивный класс, содержащий те же поведения для используемого сетевого менеджера, таким образом, вы можете жестко закодировать полученные результаты (предположения) как, например, успех неудачи, таким образом проверяя, что должно произойти для полученных " высмеял "результат.

0 голосов
/ 02 мая 2019

Вы можете написать несколько тестовых случаев, отправив различные параметры для имени пользователя и пароля.

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

Ввод правильного имени пользователя и пароля должен дать вам сообщения об успехе в качестве ответа.

Используйте XCTAssertEqual для сравнения сообщений.

На этом экране могут быть лучшие случаи UITest.

...