SketchK's Studio.

Swift Tips 011 - Structuring UI tests as extensions on XCUIApplication

字数统计: 740阅读时长: 2 min
2019/09/06 Share

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

代码截图

01.png

代码出处: Swift Tips 011 by John Sundell

小笔记

这段代码在说什么

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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 ,不能告诉你问题的根源。而造成这些问题的根源,大多数情况下都是由于系统本身的复杂性,或者代码组织的不合理造成的。

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

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

CATALOG
  1. 1. 代码截图
  2. 2. 小笔记
    1. 2.1. 这段代码在说什么
    2. 2.2. 关于测试的必要性