Как попасть в авторизованную часть в тестах пользовательского интерфейса XCode

Question

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

Каков наилучший подход для тестирования этих экранов из Авторизованной части?

У меня есть несколько идей:

1) Каким-то образом мне нужно удалить все данные из цепочки для ключей перед каждымтестирую, а затем я прохожу весь поток каждый раз, чтобы войти в первый экран после входа в систему. Когда мне нужно отправить запрос в бэкэнд для входа в систему, я жду главного экрана, используя

let nextGame = self.app.staticTexts["Main Screen Text"]
let exists = NSPredicate(format: "exists == true")
expectation(for: exists, evaluatedWithObject: nextGame, handler: nil)
waitForExpectations(timeout: 5, handler: nil)

2) Я передаю некоторые аргументы здесь

app = XCUIApplication(bundle:….)
    app.launchArguments = [“notEmptyArguments”:”value”]
    app.launch()

Так что я могу передать фальшивкуtoken и наш бэкэнд примет это token, так что мое приложение будет знать, что оно должно перенаправить меня на главный экран, и все запросы будут выполнены успешно, потому что моя сетевая служба имеет этот фальшивый token

Но я добавляю, что это не безопасный способ.

Есть ли у вас какие-либо идеи, каков наилучший подход, и, может быть, вы можете дать совет о лучшем подходе?

Answer 1

По моему мнению, ваша служба входа в систему или что-то еще service вашему приложению может потребоваться выполнить или показать некоторые варианты использования, должно быть все mocked. Это означает, что в вашей автоматизированной среде unit/ui testing ваше приложение будет взаимодействовать с реализациями поддельных служб, это означает, что ответ службы входа в систему или службы авторизации должен быть смоделирован как успешный или неудачный, чтобы вы могли протестировать оба из них.

Чтобы добиться того, чтобы все ваши сервисы были представлены в виде интерфейсов / protocols, а детали реализации / реализации должны быть либо в среде производства, разработки, либо в testing автоматизированной среде.

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

Answer 2

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

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

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

Answer 3

Вторая идея, которую вы упомянули, это хороший способ пропустить экран входа в тесты. Кроме того, реализация передачи токенов будет полезна и для команды разработчиков. Эти параметры запуска могут быть сохранены в настройках запущенных схем.

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

Конечно, эти «ярлыки» должны быть доступны только при работе с конфигурацией debug (с использованием #if DEBUG...)