构建XCTest UI测试套件的最佳实践是什么?

时间:2019-03-27 16:58:18

标签: ios objective-c xcode automated-tests xctest

我正在为iOS应用设置测试套件。我正在使用Xcode的XCTest框架。这只是一个UI测试套件。现在,我有一个带有一个文件TestAppUITests的测试目标。我所有的测试用例都驻留在该文件中(第一个问题:我所有的测试用例都应该在这里还是需要更多文件?) 在此文件中,我有一堆测试用例,它们就像是使用该应用程序的用户一样工作。登录/创建帐户,然后登录->在应用程序中导航->检查UI元素是否已加载->添加其他安全性,例如辅助电子邮件地址->注销。 这些应该如何订购?

我已经进行了全方位的研究,在各处找到了一些宝石,但是仍然有疑问。在测试目标中,您应该有多个文件吗?我的UITest目标中只有一个。 我的另一个大问题很难解释。每次我们从头开始运行测试套件时,应用程序都会在您尚未登录的状态下启动,因此,例如,为了测试类似“在应用程序中导航”的内容,我需要先运行该测试才能登录。现在,我对其进行了设置,以使登录测试运行一次,然后进行所有其他测试,然后以注销结束。但是一个文件TestAppUITests的测试用例越来越长。这是最佳做法吗?

2 个答案:

答案 0 :(得分:0)

S。让我们将其分为更多部分:

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扩展名扩展了),我进行了测试,该操作将在LoginTests扩展名中调用UITestCase+Login进行登录。

但是-您不一定需要更多的测试类-如果您决定将所有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...

这不是一个好方法(以我的拙劣观点)-将功能放入方法中(是的,我在这里重复一下自己:-))并将测试用例划分为更多文件(理想情况下是根据其功能的性质) ,通过“他们做什么”)。

希望,这对您有帮助,当我也开始进行iOS UI测试时,我也遇到了同样的问题。 哦。顺便说一句-我在medium.com上发表的有关使用XCTest进行iOS UI测试的高级策略和方法的文章将在几天内发布,一旦发布,我可以将其链接到它-应该会进一步帮助您。

答案 1 :(得分:0)

this answer相呼应,将最佳应用程序的所有测试都存储在单个文件中是违反最佳实践的,并且测试的结构应使其相互独立,仅测试单个行为在每个测试中。

将所有内容分成许多测试似乎是违反直觉的,需要在每次测试开始时重新启动您的应用程序,但这使您的测试套件更加可靠,并且由于未知数的增加,它更易于调试通过进行更短,更短的测试,可以最大程度地减少测试中的时间。由于UI测试的运行时间相对较长(可能会令人沮丧),因此您应通过确保应用程序具有良好的单元/集成测试覆盖率,来尽量减少所需的数量。

关于构建XCTest UI测试的最佳实践,您应该研究Screenplay或Page Object模型。 Page Object模型已经存在了很长时间,尽管有很多文章都集中在基于Selenium或基于Java的测试框架上,但围绕它的文章很多。我已经使用Swift和XCTest在Page Object modelScreenplay model上写过帖子,它们应该为您提供帮助。