Swift Tips 011 - Structuring UI tests as extensions on XCUIApplication

每天了解一点不一样的 Swift 小知识

代码截图

小笔记

这段代码在说什么

今天的代码是在说我们可以将测试用例里的一部分代码写成 XCUIApplication 的扩展（例如 login，logout 和 goToCategories）， 这样会更好的突出测试用例的重点。

你也许会好奇，如果不将 login, logout 这样的代码抽离出去会怎么样呢？那么下面就是一段我“还原”的测试代码，不一定完全准确，经供参考：

func testLoggingInAndOut() {
    XCTAssertFalse(app.userIsLoggedIn)

    app.launch()
    // login 相关
    app.buttons["ShowLoginVC"].tap()
    let userNameTextField = app.textFields["用户名"]
    userNameTextField.tap()
    userNameTextField.typeText("SketchK")
    let passwordTextField = app.textFields["密码"]
    passwordTextField.tap()
    passwordTextField.typeText("123")
    app.buttons["Login"].tap()
    XCTAssertTrue(app.userIsLoggedIn)

    // logout 相关
    app.buttons["ShowUserVC"].tap()
    app.buttons["Logout"].tap()
    XCTAssertFalse(app.userIsLoggedIn)
}

从这里，我们已经可以看出上面的代码在阅读体验上变差了很多，而且也增加了理解方面的成本。

所以 John Sundell 认为每次把这样的代码写在 Test Case 里面是不合适的，可以将这些代码可以做成 XCUIApplication 的 categories 来管理，从而让我们的 Test Case 看起来更加简洁，也更容易突出重点。

关于测试的必要性

我所在的公司很少会看到有开发人员写测试代码，一方面是因为业务压力大，留给开发人员写测试的时间几乎为零。另一个方面是测试的价值并没有被团队或者公司文化所接纳，团队更倾向于把剩下的问题交给 QA 来负责。

虽然我们目前不需要写任何测试代码，但不代表这种现状是 ok 的，我们的 app 里各个对象间的关系变得越来越复杂，一个小小的改动都有可能触发极其复杂的连锁反应。有时候为了保险起见，我们会无脑交给 QA 进行所谓的回归测试。这时候如果只有纯粹的手工测试，会面临两个问题：

• 难以确定测试的边界
• 极大的测试人力耗费。

可即使完成了这些回归测试，QA 也只能告诉你出了 bug ，不能告诉你问题的根源。而造成这些问题的根源，大多数情况下都是由于系统本身的复杂性，或者代码组织的不合理造成的。

我很认同这样一种说法：可测试的代码不一定是好代码，但坏代码几乎是不可能被测试的。深度耦合的代码，写他们的单元测试，难于上青天；但反过来，我们可以拿“可测试”为标准，不断的完善并重构代码，只要这样坚持下来，最终的代码质量都不会差到哪里去。

说了这么多，你对测试的必要性是怎么看待的呢？