Soo. Давайте разделим это на несколько частей:
1 / Should all of my test cases be in here or do I need more files?
Что ж, ваши тесты такие же, как и у любого другого кода приложения. У вас есть весь код приложения в одном файле? Вероятно, нет, поэтому хорошей практикой является разделение ваших тестов на несколько классов (я делаю это так, как они тестируют - LoginTests класс, UserProfileTests класс и т. Д. И т. Д.).
Чтобы пойти дальше - у меня есть тестовые классы и методы, разделенные на отдельные файлы - например, У меня есть метод, который будет выполнять вход в систему в тесте пользовательского интерфейса, поэтому у меня есть метод в расширении UITestCase+Login (UITestCase - это класс, который расширяется всеми этими расширениями UITestCase+Something), и у меня есть тест, который выполнит вход в систему LoginTests, в которой я вызываю метод входа из расширения UITestCase+Login.
Однако - вам не обязательно больше тестовых классов - если вы решите собрать все свои тесты пользовательского интерфейса в одном классе, это ваш выбор. Все будет работать, но наличие тестов и методов, которые эти тесты используют в отдельных файлах, является хорошей практикой для будущей разработки тестов и методов.
2 / ... Add additional security like secondary email address... How should these be ordered?
Закажите их в методы и вызовите их в тестах.
Это мой метод ожидания некоторого сообщения пользовательского интерфейса, когда я использую неверные учетные данные для входа в систему:
func expectInvalidCredentialsErrorMessageAfterLoggingWithInvalidBIDCredentials() {
let alertText = app.alerts.staticTexts[localizedString("mobile.account.invalid_auth_credentials")]
let okButton = app.alerts.buttons[localizedString("common.ok")]
wait(
until: alertText.exists && okButton.existsAndHittable,
timeout: 15,
or: .fail(message: "Alert text/button are not visible.")
)
okButton.tap()
}
И это мое использование в тесте:
func testTryToLoginWitMissingBIDAndExpectError() {
let inputs = BIDLoginInputs(
BID: "",
email: "someemail@someemail.com",
departureIATA: "xxx",
dayOfDeparture: "xx",
monthOfDeparture: "xxx",
yearOfDeparture: "xxx"
)
loginWithBIDFromProfile(inputs: inputs)
expectInvalidCredentialsErrorMessageAfterLoggingWithInvalidBIDCredentials()
}
Вы можете видеть, что тесты очень удобочитаемы и что они (почти полностью) состоят из методов, которые можно повторно использовать в других тестах.
3 / Within the test target, should you have multiple files?
Опять же - это ваше дело, однако наличие всего в одном файле не очень хорошо для сопровождения и дальнейшей разработки этих тестов.
4 / ... Each time we run the test suite from the beginning the app starts in a state where you are not logged in...Right now I have it setup so that the login test runs once, then all other tests after it, then ends with logout...
Не очень хороший подход (с моей скромной точки зрения). Поместить функциональность в методы (да, я повторяюсь здесь :-)) и разделить контрольные примеры на большее количество файлов (в идеале по характеру их функциональности). , "что они делают").
Надеюсь, это вам помогло, я много боролся с одними и теми же вопросами, когда тоже начинал с тестов пользовательского интерфейса iOS.
Ой. И между прочим - моя статья на medium.com о продвинутой тактике и подходах к тестированию пользовательского интерфейса iOS с XCTest выходит через несколько дней, я могу добавить ссылку на нее, как только она выйдет - это должно помочь вам еще больше.