我正在为 iOS 应用程序设置测试套件。我正在使用Xcode的XCTest框架。这只是一个 UI 测试套件。现在我有一个带有一个文件的测试目标 测试应用程序UITests.我所有的测试用例都驻留在这个文件中(第一个问题：我所有的测试用例都应该在这里还是我需要更多文件？ 在这个文件中，我有一堆测试用例，就像使用该应用程序的用户一样工作。登录/创建帐户然后登录 -> 在应用程序中导航 -> 检查 UI 元素是否已加载 -> 添加额外的安全性，如辅助电子邮件地址 ->注销。 这些应该如何订购？
我已经四处研究了，在这里和那里发现了一些宝石，但仍然有疑问。在测试目标中，是否应该有多个文件？我只有我的 UITest 目标中的那个。 我的另一个大问题有点难以解释。每次我们从一开始就运行测试套件时，应用程序都会以您未登录的状态启动，因此，例如，为了测试诸如在应用程序内导航之类的内容，我需要先运行该测试以登录。现在我已经设置了它，以便登录测试运行一次，然后运行所有其他测试，然后以注销结束。但是一个文件TestAppUITests变得非常长，有大量的测试用例。这是最佳实践吗？
是这样。让我们将其分为更多部分：
1/Should all of my test cases be in here or do I need more files?
好吧 - 您的测试与任何其他应用程序代码相同，您拥有。您是否将所有应用程序代码都放在一个文件中？可能不是，所以一个好的做法是将你的测试分成更多的类(我按照他们测试的方式做 -LoginTests类、UserProfileTests类等)。
为了更进一步 - 我将测试类和方法划分为单独的文件 - f.e.我有一个方法，可以在 UI 测试中进行登录，所以我在UITestCase+Login扩展中都有该方法(UITestCase是一个类，由所有这些UITestCase+Something扩展扩展)，我有测试，它将在我从UITestCase+Login扩展调用登录方法的LoginTests中进行登录。
但是 - 您不一定需要更多的测试类 - 如果您决定将所有 UI 测试放在一个类中，那是您的选择。一切都会正常工作，但是将这些测试使用的测试和方法放在单独的文件中只是将来开发测试和方法的良好做法。
2/... Add additional security like secondary email address... How should these be ordered?
将它们排序到方法中，并在测试中调用它们。
这是我在使用无效登录凭据时期望某些 UI 消息的方法：
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...
不是一个好方法(以我的拙见 ofc.) - 将功能放入方法中(是的，我在这里重复自己：-))并将测试用例划分为更多文件(理想情况下，根据其功能的性质，通过"它们做什么")。
希望这对您有所帮助，当我开始使用iOS UI测试时，我在同样的问题上挣扎了很多。 哦。顺便说一句 - 我关于使用 XCTest 进行 iOS UI 测试的高级策略和方法的 medium.com 的文章将在几天内发布，我可以在发布后放置一个链接 - 这应该会进一步帮助您。
呼应这个答案，将复杂应用程序的所有测试存储在单个文件中是违反最佳实践的，并且您的测试应该结构化，以便它们彼此独立，在每个测试中只测试一个行为。
将所有内容拆分为许多测试似乎违反直觉，这些测试需要在每次测试开始时重新启动您的应用程序，但这会使您的测试套件更可靠且更易于调试，因为通过更小、更短的测试可以最大限度地减少测试中的未知数。由于 UI 测试需要相对较长的时间才能运行，这可能会令人沮丧，因此应尝试通过确保应用具有良好的单元/集成测试覆盖率来最大程度地减少所需的量。
关于构建 XCTest UI 测试的最佳实践，您应该研究屏幕或页面对象模型。页面对象模型已经存在了很长时间，并且有很多关于它的文章，尽管许多帖子倾向于关注Selenium或基于Java的测试框架。我已经使用 Swift 和 XCTest 写过关于页面对象模型和 Screenplay 模型的文章，它们应该对您有所帮助。