Методы модульного тестирования, которые обновляют элементы пользовательского интерфейса в iOS - PullRequest
0 голосов
/ 17 апреля 2019

Я пытаюсь написать модульные тесты для моего существующего кода. У меня есть 3 метода.

func methodOne() {
    // code
    methodTwo()
}

func methodTwo() {
    // code
    methodThree()
}

func methodThree() {
    // code
    // update UI element
}

Какой идеальный способ для юнит-тестирования таких методов. В то время как модульное тестирование methodTwo() вызывает methodThree(), поскольку элементы пользовательского интерфейса не загружены, они имеют значение nil при вызове methodThree(). Как объединить методы тестирования, которые включают элементы пользовательского интерфейса. Я не хочу проверять, правильно ли загружен элемент пользовательского интерфейса, я просто хочу проверить код в methodTwo() и methodThree(). Есть ли способ обойти элементы интерфейса, связанные с кодом. Любая помощь приветствуется. Спасибо.

Ответы [ 2 ]

0 голосов
/ 17 апреля 2019

Привет @ Pradeep ?, добро пожаловать в StackOverflow.

Исходя из того, как вы описываете сбои, которые вы испытываете, я предполагаю, что ваши методы @IBOutlet s в UIViewController, это правильно?

Если это так, вы можете сделать так, чтобы тесты инициализировали представление UIViewController, выполнив что-то вроде перед , вызвав методы, которые зависят от доступности представления:

_ = viewControllerUnderTest.view

или

viewControllerUnderTest.beginAppearanceTransition(true, animated: false)

Этот - достойный пост, чтобы узнать больше о возможностях тестирования UIViewController s, , в этом есть более продвинутый подход, который может помочь вам, если вы в конечном итоге много напишите тестов с зависимостями от вида, как вы описали.

Я бы посоветовал вам хранить как можно больше кода бизнес-логики, начиная с UIViewController с и UIView с. Жизненный цикл этих классов усложняет их тестирование, и чем проще вы можете сделать что-то для тестирования, тем лучше.

Напишите всю свою бизнес-логику в выделенных class es и struct s, их будет проще протестировать, если они не подклассифицируют другие типы. Используйте UIViewController s только в качестве связующего кода, чтобы показывать данные пользователю и направлять их входные данные в вашу бизнес-логику, так что вам придется написать только несколько простых тестов. Оставьте UIView s скромным , только для логики их настройки.

( Если мое UIViewController предположение было неверным, пожалуйста, добавьте больше деталей, и мы найдем способ, чтобы ваши тесты не вылетали. )

0 голосов
/ 17 апреля 2019

Лучший способ сделать это - отделить код, который вы хотите протестировать, от своего пользовательского интерфейса, насколько это возможно. Это можно сделать, поместив часть //code в methodTwo в ее собственную функцию (т.е. methodFour) и вызвав ее из methodTwo. Тогда ваш код будет выглядеть так:

func methodTwo() {
     methodFour()
     methodThree()
}

func testMethodFour() {
     methodFour()
     // check assumptions
}

func methodFour() {
     // code that you originally had in methodTwo before methodThree
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...