区块链技术博客
www.b2bchain.cn

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性求职学习资料

本文介绍了【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性求职学习资料,有助于帮助完成毕业设计以及求职,是一篇很好的资料。

对技术面试,学习经验等有一些体会,在此分享。

翁子林(编程小翁),iOS 老兵,曾先后供职于星网锐捷、阿里巴巴,现为美图公司宜肤事业部 iOS Lead。正与一群有情有义的小伙伴投身于 AI 测肤与物联网开发事业中。

审核:NathanSun

一、前言

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

单元测试与 UI 测试往往能为产品的交付提供可靠的保障。一些公司甚至有专门的测试开发工程师以及移动端开发工程师编写大量的测试用例来提高代码的稳定性。在 WWDC21 中,Apple 为开发者提供了不少令人欣喜的新特性以及 API ,可以提高编写测试用例的效率。现在,让我们一起开启一场关于 Testing 新特性的探索之旅。

这篇文章是基于 Session 10296、Session 10207、Session 10208 基础上加入个人理解写出,如有疏漏欢迎指正,老司机技术周报以后也会有更多文章做更全面的探讨,欢迎持续关注~

二、本届 XCTest 值得期待的特性

我们不急着看新 API,先来看个故事。假定公司有员工 A 和员工 B 共同开发完成一个复杂模块并开始写测试用例自测。我们用代码来描述以上场景,如下:

class ComplexModule {     static func stuffA_DoSomethingReturnTrue() -> Bool {         return true     }     static func stuffB_DoSomethingReturnTrue() -> Bool {         return true     } }  class DiagnoseWithTestRepetitionsTests: XCTestCase {      func testXCTExpectFailure() throws {         XCTAssertTrue(ComplexModule.stuffA_DoSomethingReturnTrue())         XCTAssertTrue(ComplexModule.stuffB_DoSomethingReturnTrue())     }     // ... }

这时,员工 A 发现代码逻辑有严重缺陷需要部分重构,员工 B 继续开发测试用例自测。假定二人在同个分支开发(别抬杠,简化问题)。那问题来了,由于 A 的重构导致 stuffA_DoSomethingReturnTrue 等大量功能的返回值出错,间接导致员工 B 的测试用例报告出现很多 fail 干扰项,严重影响自测效率。

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

员工 B 有什么方式可以临时屏蔽干扰项?有 2 种方式:

  1. 注释大法,把所有员工 A 的 XCTAssert 相关方法注释掉,并且打上标记,过段时间恢复
  2. XCTSkip 相关函数跳过(相关介绍点击这里):

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

注意到左上角,发现 testXCTExpectFailure 这个 test case 不再标红,DiagnoseWithTestRepetitionsTests 这个 Suite 也已经通过。但使用 XCTSkip 代价很大,我们调整了函数顺序,因为 XCTSkip 函数会把作用域内当前行之后的代码全部屏蔽。因此,用来屏蔽干扰并不合适。

接下来,我们一起看看更优雅的方式。

2.1 XCTExpectFailure

XCTExpectFailure 是 Apple 设计用来声明即将出现预期 Assert fail 的 API。在看完 Session 视频以及接口描述后,我个人认为非常适合在重构代码或者功能开发过程中起到代码临时屏蔽的作用,让测试的 workflow 更顺畅。从 Apple 的 API 注释里也可以感受到 Apple 也有相近的设计初衷:

@function XCTExpectFailure() This can be used to both document and suppress a known issue when immediate resolution is not possible.

现在我们看下用 XCTExpectFailure 如何优雅解决员工 B 的困扰:

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

可以看出,虽然员工 A 提供的 stuffA_DoSomethingReturnTrue 服务依旧异常(本来为 true 却返回了 false),但并不影响员工 B 的测试报告。灰色打叉代表用例内虽然有错误,但在预期内,不算作 fail。整个 test suite 依旧是绿色标志。

当员工 A 调整代码让 stuffA_DoSomethingReturnTrue 返回值恢复正常后,我们看下会发生什么:

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

出现了 fail !因为系统抛出了 UnmatchedExpectedFailure,因为代码预期会有个失败,但实际逻辑并未抛出。我们正好可以用依据报错的提示,逐个去掉 XCTExpectFailure 临时代码,优雅地完成代码重构

另外,接口还允许追加参数:

XCTExpectFailure("PRD地址是 <www.meitu.com>", options: XCTExpectedFailure.Options()) {     XCTAssertTrue(ComplexModule.stuffA_DoSomethingReturnTrue()) }

第一个参数是 reason,可以在这里添加注释以及链接。比如可以插入产品文档地址或者 Jira bug 地址。如果 reason 字段带有链接,则在测试报告列表中会多出一个「昆虫」图标,点击图标会自动唤起 Mac 浏览器并打开网页。这方便了我们查看用例报告时了解更多上下文信息。挺实用的小 Tips !

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

XCTExpectFailure 还有一些使用上的注意事项,下面逐条列出。

我习惯先解释原理,只要原理掌握了,剩下的就是 API 语法细节了,小问题~

  1. XCTExpectFailure 也可以不带 block 参数使用,这时表示你期望作用域内 XCTExpectFailure之后的代码有 fail。
  2. XCTExpectFailure 可以嵌套调用,也就是在其 block 内嵌套调用
  3. 支持通过 XCTExpectedFailure.Options 参数灵活配置 isEnableisStrict,并通过 issueMatcher 闭包添加触发的过滤条件。
  4. reason 字段如果是文字 + 网址的格式,则网址必须用尖括号包起来,比如” please refer to www.google.com61 ”,否则 Xcode 将无法识别地址。

2.2 Test Repetitions

在产品开发过程中,令程序员与测试心惊胆战的一类问题就是「非必现 BUG 」。这类问题往往由线程安全、子线程执行 UI、全局变量改变等因素导致。测试组常常通过 Appium 等框架做自动化测试,对开发而言,我们往往需要在单元测试中搭配 Address Sanitizer、Thread SanitizerMain Thread CheckerUndefined Behavior Sanitizer 等调试选项,甚至执行多遍代码才能高概率复现此类「非必现 BUG」。

Xcode 13 之前,要执行多次代码往往需要程序员编写遍历逻辑以及停止条件来实现。 Xcode 13 将释放开发的双手,在功能上做多次 Test 的支持。Xcode 13 提供了三种重复模式:

触发 Repetition Test 的入口可以在 testXXX 函数的小钻石图标上右键 -> 选择 「Run “testXXX()” Repeatedly…」

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

模式 1. Stop after failure

该模式下,测试用例会反复执行直到出现第一次 Assert Failed 或者循环次数达到 Maximum Repetitions 设定的值。

例如下面的代码:

    func testRepetitions() throws {         let random = arc4random() % 50         XCTAssertNotEqual(random, 25)     }

使用 Stop after failure 模式,最大循环次数设置为 10 次:

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

翁子林(编程小翁),iOS 老兵,曾先后供职于星网锐捷、阿里巴巴,现为美图公司宜肤事业部 iOS Lead。正与一群有情有义的小伙伴投身于 AI 测肤与物联网开发事业中。

审核:NathanSun

一、前言

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

单元测试与 UI 测试往往能为产品的交付提供可靠的保障。一些公司甚至有专门的测试开发工程师以及移动端开发工程师编写大量的测试用例来提高代码的稳定性。在 WWDC21 中,Apple 为开发者提供了不少令人欣喜的新特性以及 API ,可以提高编写测试用例的效率。现在,让我们一起开启一场关于 Testing 新特性的探索之旅。

这篇文章是基于 Session 10296、Session 10207、Session 10208 基础上加入个人理解写出,如有疏漏欢迎指正,老司机技术周报以后也会有更多文章做更全面的探讨,欢迎持续关注~

二、本届 XCTest 值得期待的特性

我们不急着看新 API,先来看个故事。假定公司有员工 A 和员工 B 共同开发完成一个复杂模块并开始写测试用例自测。我们用代码来描述以上场景,如下:

class ComplexModule {     static func stuffA_DoSomethingReturnTrue() -> Bool {         return true     }     static func stuffB_DoSomethingReturnTrue() -> Bool {         return true     } }  class DiagnoseWithTestRepetitionsTests: XCTestCase {      func testXCTExpectFailure() throws {         XCTAssertTrue(ComplexModule.stuffA_DoSomethingReturnTrue())         XCTAssertTrue(ComplexModule.stuffB_DoSomethingReturnTrue())     }     // ... }

这时,员工 A 发现代码逻辑有严重缺陷需要部分重构,员工 B 继续开发测试用例自测。假定二人在同个分支开发(别抬杠,简化问题)。那问题来了,由于 A 的重构导致 stuffA_DoSomethingReturnTrue 等大量功能的返回值出错,间接导致员工 B 的测试用例报告出现很多 fail 干扰项,严重影响自测效率。

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

员工 B 有什么方式可以临时屏蔽干扰项?有 2 种方式:

  1. 注释大法,把所有员工 A 的 XCTAssert 相关方法注释掉,并且打上标记,过段时间恢复
  2. XCTSkip 相关函数跳过(相关介绍点击这里):

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

注意到左上角,发现 testXCTExpectFailure 这个 test case 不再标红,DiagnoseWithTestRepetitionsTests 这个 Suite 也已经通过。但使用 XCTSkip 代价很大,我们调整了函数顺序,因为 XCTSkip 函数会把作用域内当前行之后的代码全部屏蔽。因此,用来屏蔽干扰并不合适。

接下来,我们一起看看更优雅的方式。

2.1 XCTExpectFailure

XCTExpectFailure 是 Apple 设计用来声明即将出现预期 Assert fail 的 API。在看完 Session 视频以及接口描述后,我个人认为非常适合在重构代码或者功能开发过程中起到代码临时屏蔽的作用,让测试的 workflow 更顺畅。从 Apple 的 API 注释里也可以感受到 Apple 也有相近的设计初衷:

@function XCTExpectFailure() This can be used to both document and suppress a known issue when immediate resolution is not possible.

现在我们看下用 XCTExpectFailure 如何优雅解决员工 B 的困扰:

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

可以看出,虽然员工 A 提供的 stuffA_DoSomethingReturnTrue 服务依旧异常(本来为 true 却返回了 false),但并不影响员工 B 的测试报告。灰色打叉代表用例内虽然有错误,但在预期内,不算作 fail。整个 test suite 依旧是绿色标志。

当员工 A 调整代码让 stuffA_DoSomethingReturnTrue 返回值恢复正常后,我们看下会发生什么:

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

出现了 fail !因为系统抛出了 UnmatchedExpectedFailure,因为代码预期会有个失败,但实际逻辑并未抛出。我们正好可以用依据报错的提示,逐个去掉 XCTExpectFailure 临时代码,优雅地完成代码重构

另外,接口还允许追加参数:

XCTExpectFailure("PRD地址是 <www.meitu.com>", options: XCTExpectedFailure.Options()) {     XCTAssertTrue(ComplexModule.stuffA_DoSomethingReturnTrue()) }

第一个参数是 reason,可以在这里添加注释以及链接。比如可以插入产品文档地址或者 Jira bug 地址。如果 reason 字段带有链接,则在测试报告列表中会多出一个「昆虫」图标,点击图标会自动唤起 Mac 浏览器并打开网页。这方便了我们查看用例报告时了解更多上下文信息。挺实用的小 Tips !

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

XCTExpectFailure 还有一些使用上的注意事项,下面逐条列出。

我习惯先解释原理,只要原理掌握了,剩下的就是 API 语法细节了,小问题~

  1. XCTExpectFailure 也可以不带 block 参数使用,这时表示你期望作用域内 XCTExpectFailure之后的代码有 fail。
  2. XCTExpectFailure 可以嵌套调用,也就是在其 block 内嵌套调用
  3. 支持通过 XCTExpectedFailure.Options 参数灵活配置 isEnableisStrict,并通过 issueMatcher 闭包添加触发的过滤条件。
  4. reason 字段如果是文字 + 网址的格式,则网址必须用尖括号包起来,比如” please refer to www.google.com61 ”,否则 Xcode 将无法识别地址。

2.2 Test Repetitions

在产品开发过程中,令程序员与测试心惊胆战的一类问题就是「非必现 BUG 」。这类问题往往由线程安全、子线程执行 UI、全局变量改变等因素导致。测试组常常通过 Appium 等框架做自动化测试,对开发而言,我们往往需要在单元测试中搭配 Address Sanitizer、Thread SanitizerMain Thread CheckerUndefined Behavior Sanitizer 等调试选项,甚至执行多遍代码才能高概率复现此类「非必现 BUG」。

Xcode 13 之前,要执行多次代码往往需要程序员编写遍历逻辑以及停止条件来实现。 Xcode 13 将释放开发的双手,在功能上做多次 Test 的支持。Xcode 13 提供了三种重复模式:

触发 Repetition Test 的入口可以在 testXXX 函数的小钻石图标上右键 -> 选择 「Run “testXXX()” Repeatedly…」

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

模式 1. Stop after failure

该模式下,测试用例会反复执行直到出现第一次 Assert Failed 或者循环次数达到 Maximum Repetitions 设定的值。

例如下面的代码:

    func testRepetitions() throws {         let random = arc4random() % 50         XCTAssertNotEqual(random, 25)     }

使用 Stop after failure 模式,最大循环次数设置为 10 次:

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

翁子林(编程小翁),iOS 老兵,曾先后供职于星网锐捷、阿里巴巴,现为美图公司宜肤事业部 iOS Lead。正与一群有情有义的小伙伴投身于 AI 测肤与物联网开发事业中。

审核:NathanSun

一、前言

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

单元测试与 UI 测试往往能为产品的交付提供可靠的保障。一些公司甚至有专门的测试开发工程师以及移动端开发工程师编写大量的测试用例来提高代码的稳定性。在 WWDC21 中,Apple 为开发者提供了不少令人欣喜的新特性以及 API ,可以提高编写测试用例的效率。现在,让我们一起开启一场关于 Testing 新特性的探索之旅。

这篇文章是基于 Session 10296、Session 10207、Session 10208 基础上加入个人理解写出,如有疏漏欢迎指正,老司机技术周报以后也会有更多文章做更全面的探讨,欢迎持续关注~

二、本届 XCTest 值得期待的特性

我们不急着看新 API,先来看个故事。假定公司有员工 A 和员工 B 共同开发完成一个复杂模块并开始写测试用例自测。我们用代码来描述以上场景,如下:

class ComplexModule {     static func stuffA_DoSomethingReturnTrue() -> Bool {         return true     }     static func stuffB_DoSomethingReturnTrue() -> Bool {         return true     } }  class DiagnoseWithTestRepetitionsTests: XCTestCase {      func testXCTExpectFailure() throws {         XCTAssertTrue(ComplexModule.stuffA_DoSomethingReturnTrue())         XCTAssertTrue(ComplexModule.stuffB_DoSomethingReturnTrue())     }     // ... }

这时,员工 A 发现代码逻辑有严重缺陷需要部分重构,员工 B 继续开发测试用例自测。假定二人在同个分支开发(别抬杠,简化问题)。那问题来了,由于 A 的重构导致 stuffA_DoSomethingReturnTrue 等大量功能的返回值出错,间接导致员工 B 的测试用例报告出现很多 fail 干扰项,严重影响自测效率。

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

员工 B 有什么方式可以临时屏蔽干扰项?有 2 种方式:

  1. 注释大法,把所有员工 A 的 XCTAssert 相关方法注释掉,并且打上标记,过段时间恢复
  2. XCTSkip 相关函数跳过(相关介绍点击这里):

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

注意到左上角,发现 testXCTExpectFailure 这个 test case 不再标红,DiagnoseWithTestRepetitionsTests 这个 Suite 也已经通过。但使用 XCTSkip 代价很大,我们调整了函数顺序,因为 XCTSkip 函数会把作用域内当前行之后的代码全部屏蔽。因此,用来屏蔽干扰并不合适。

接下来,我们一起看看更优雅的方式。

2.1 XCTExpectFailure

XCTExpectFailure 是 Apple 设计用来声明即将出现预期 Assert fail 的 API。在看完 Session 视频以及接口描述后,我个人认为非常适合在重构代码或者功能开发过程中起到代码临时屏蔽的作用,让测试的 workflow 更顺畅。从 Apple 的 API 注释里也可以感受到 Apple 也有相近的设计初衷:

@function XCTExpectFailure() This can be used to both document and suppress a known issue when immediate resolution is not possible.

现在我们看下用 XCTExpectFailure 如何优雅解决员工 B 的困扰:

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

可以看出,虽然员工 A 提供的 stuffA_DoSomethingReturnTrue 服务依旧异常(本来为 true 却返回了 false),但并不影响员工 B 的测试报告。灰色打叉代表用例内虽然有错误,但在预期内,不算作 fail。整个 test suite 依旧是绿色标志。

当员工 A 调整代码让 stuffA_DoSomethingReturnTrue 返回值恢复正常后,我们看下会发生什么:

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

出现了 fail !因为系统抛出了 UnmatchedExpectedFailure,因为代码预期会有个失败,但实际逻辑并未抛出。我们正好可以用依据报错的提示,逐个去掉 XCTExpectFailure 临时代码,优雅地完成代码重构

另外,接口还允许追加参数:

XCTExpectFailure("PRD地址是 <www.meitu.com>", options: XCTExpectedFailure.Options()) {     XCTAssertTrue(ComplexModule.stuffA_DoSomethingReturnTrue()) }

第一个参数是 reason,可以在这里添加注释以及链接。比如可以插入产品文档地址或者 Jira bug 地址。如果 reason 字段带有链接,则在测试报告列表中会多出一个「昆虫」图标,点击图标会自动唤起 Mac 浏览器并打开网页。这方便了我们查看用例报告时了解更多上下文信息。挺实用的小 Tips !

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

XCTExpectFailure 还有一些使用上的注意事项,下面逐条列出。

我习惯先解释原理,只要原理掌握了,剩下的就是 API 语法细节了,小问题~

  1. XCTExpectFailure 也可以不带 block 参数使用,这时表示你期望作用域内 XCTExpectFailure之后的代码有 fail。
  2. XCTExpectFailure 可以嵌套调用,也就是在其 block 内嵌套调用
  3. 支持通过 XCTExpectedFailure.Options 参数灵活配置 isEnableisStrict,并通过 issueMatcher 闭包添加触发的过滤条件。
  4. reason 字段如果是文字 + 网址的格式,则网址必须用尖括号包起来,比如” please refer to www.google.com61 ”,否则 Xcode 将无法识别地址。

2.2 Test Repetitions

在产品开发过程中,令程序员与测试心惊胆战的一类问题就是「非必现 BUG 」。这类问题往往由线程安全、子线程执行 UI、全局变量改变等因素导致。测试组常常通过 Appium 等框架做自动化测试,对开发而言,我们往往需要在单元测试中搭配 Address Sanitizer、Thread SanitizerMain Thread CheckerUndefined Behavior Sanitizer 等调试选项,甚至执行多遍代码才能高概率复现此类「非必现 BUG」。

Xcode 13 之前,要执行多次代码往往需要程序员编写遍历逻辑以及停止条件来实现。 Xcode 13 将释放开发的双手,在功能上做多次 Test 的支持。Xcode 13 提供了三种重复模式:

触发 Repetition Test 的入口可以在 testXXX 函数的小钻石图标上右键 -> 选择 「Run “testXXX()” Repeatedly…」

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

模式 1. Stop after failure

该模式下,测试用例会反复执行直到出现第一次 Assert Failed 或者循环次数达到 Maximum Repetitions 设定的值。

例如下面的代码:

    func testRepetitions() throws {         let random = arc4random() % 50         XCTAssertNotEqual(random, 25)     }

使用 Stop after failure 模式,最大循环次数设置为 10 次:

【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性

部分转自互联网,侵权删除联系

赞(0) 打赏
部分文章转自网络,侵权联系删除b2bchain区块链学习技术社区 » 【WWDC21 10296】探索 iOS15 XCTest 与 UITest 新特性求职学习资料
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

b2b链

联系我们联系我们