Preface(废话)

如果你已经有过一些开发经验,做过一些APP开发,那么你一定对下面的故事很熟悉

公司发布了一个新APP的开发计划.然后你开始收集功能点,分析具体需求,然后项目经理把需求文档拿给你,美工同学把精美的原型图发给你.接着,你使出洪荒之力,一目十行的把需求文档过了一遍,此时你胸中已有丘壑;下面是时候表现真正技术了,coding...

创建项目,然后开始对着功能点一步步实现功能,让一个APP从原型图变成一个真正的APP,这个过程中,你一定遇到过下面这样的情况:

你需要写一个表单提交,而这个表单位于导航栏的很深的层次,你一层层的写好以后,你觉得应该验证一下自己的代码,于是乎你开始疯狂的穿梭于代码和模拟器之间;第一次发现表单的第一行没有做非法验证,第二遍发现验证的覆盖面不够,第三遍发现没有做断网测试

第四遍…

第五遍…

第六…

遍...

...

每一遍你都从第一个界面开始手动点到你要到达的目的地,然后手动输入你要测试的数据,发现不通过,回头修改代码,然后重复上面的步骤...

如果你也曾经这么干过,请默默的点个赞...

如果你现在还在这么干,请默默的在评论区,抠1...

其实在iOS开发中,完全可以通过UI测试+单元测试,解决上面的问题,让机器代替你一遍遍的Command + R

创建单元测试和UI测试

给新的项目创建测试模块

创建测试

如果你的项目在创建之时,没有勾上Include Tests选项,你还可以通过下面方式来为现有项目添加单元测试或UI测试

给已有项目添加测试 Step 1 

当你创建好单元测试以后,在你的项目目录里面会有一个以你的项目名为前缀,后面加一个Tests的文件夹,打开里面的一个默认文件,就可以看到系统为你生成的测试代码.打开文件你能看到如下一段代码:

import XCTest
@testable import UnitTest // 这里是导入工程模块,使得整个工程中的代码在该测试用例中都可以引用到

class UnitTestTests: XCTestCase {
    
    override func setUp() {
        super.setUp()
        // 测试前要做的工作
    }
    
    override func tearDown() {
        super.tearDown()
        // 测试结束后要做的工作
    }
    
    func testExample() {
        // 测试代码
    }
    
    func testPerformanceExample() {
        // This is an example of a performance test case.
        self.measure {
            // Put the code you want to measure the time of here.
        }
    }
}

上面这段代码,有两个方法要注意:

• setUP() -> 在测试代码运行前调用
• tearDown() -> 在测试代码运行结束后调用

而且,在测试代码中,测试方法一定要使用test开头来命名方法名,不然无法单独运行该测试方法,后面会讲如何单独运行测试方法

如何测试?

UI Tests

UI Tests就是拿来做UI测试的(呃...这么解释似乎有点儿2)

而且使用方法相对比较简单,方法如下图:

执行UI Test

在点击开始Record UI Test按钮以后,Xcode会运行模拟器来启动你的APP,接下来你在APP所有的操作都会被记录下来,同时Xcode会在UI Tests相对应的Test Case文件里面生成对应的代码,所有的操作完成以后,再次点击Record UI Test按钮(其实这时候已经变成Stop状态)来完成记录

Case:

假如你有这样一个登录界面

登录界面

当你的所有代码写完以后,你想测试一下你的帐号验证做的是否全面,比如检测汉字,验证手机号的合法性,以及检测出错误以后,提示信息是否正确显示等等...

那么这个时候你就可以使用UI Tests来做这个事情,而且效率很高当你记录完以后,你的Test Case里面会生成一段代码:

let elementsQuery = XCUIApplication().otherElements.containing(.staticText, identifier:"帐号")
let textField = elementsQuery.children(matching: .textField).matching(identifier: "输入数字").element(boundBy: 0)
textField.tap()
textField.typeText("1xxxxx")
        
let textField2 = elementsQuery.children(matching: .textField).matching(identifier: "输入数字").element(boundBy: 1)
textField2.typeText("xx")
textField2.tap()
textField2.tap()
textField2.typeText("123456")

上面这段代码中的typeText参数你是可以手动修改的,改完以后直接Command + U可以直接运行测试,然后Xcode会自动测试你修改过的内容;这些代码完全可以自己手写进去,然后直接执行UI测试,如果你开始的时候不熟悉相关的代码,你可以先让系统生成,然后去修改,慢慢的你就会成为老司机的,发车那是小Case

有时候你可能只想运行某条单个测试,而不是Command + U运行当前Test Case所有的测试方法,你可以通过点击跟测试方法名同行位于右侧的小按钮来运行那一条测试:

执行单条测试

已经通过的测试,按钮会编程一个绿色的对号,表示已经通过测试

还未运行的是一个灰色的菱形

Unit Tests

在开发中,UI Test只能去测试界面跳转以及输入反馈等一些界面性的测试.然而,事实上我们还需要去测试,诸如方法已经网络交互等.

这个时候我可以脑补,很多同学的各种NSLog()和Print()代码,其实不需要这么麻烦,我们可以通过Unit Test代码来完成这些工作;

Case:

我们在上面的界面里面输入帐号和密码,然后去验证帐号和密码的合法性等工作完成后,通常就会向服务器发起登录请求,不管登录成功与否,服务那边都会返回一些数据;比如成功后返回一个Success,失败返回一个Failure

func postForLoginAction(response: String) -> String {
    if response.contains("Failure") { 
        return "Failure !"
    } else {
        return "Success !"
    }
}

这个时候我们可以在Unit Test里面写一个Test Method来做个事情,去验证返回结果的正确性

func testNumberOfVowelsInString_shouldReturnNumberOfVowels() {
    let viewController = ViewController()
    let string = "Failure"
    let results = viewController.postForLoginAction(response: "xxx")
    XCTAssertEqual(string, results, "登录失败,返回结果: \(results)")
}

这里使用了XCTest框架里面的一个断言函数XCTAssertEqual(_:_:message:),他是用来检测两个表达式是否相等,最后一个参数是在不等的情况下会log的信息;

在写测试的时候会有很多类似XCTAssertEqual的方法被调用到,下面列举一些常用的:

• XCTAssertTrue(_:_:file:line:): 判断结果是否为真
• XCTAssertFalse(_:_:file:line:):判断结果是否为假
• XCTAssertEqual(_:_:_:file:line:): 判断两个表达式是否相等
• XCTAssertNotEqual(_:_:_:file:line:): 判断不相等
• XCTAssertNil(_:_:file:line:): 判断结果是否为nil
• XCTAssertNotNil(_:_:file:line:): 判断是否为非nil

有兴趣的同学可以进入XCTest里面查找一下,有很多个,而且命名方式都非常的语义化,还是比较容易理解的

Unit Tests的运行方法和UI Tests有些区别,Unit Tests并没有自动记录功能,所有只能Command + U来进行测试

当然,Unit Tests也可以进行单条测试,方法同UI Tests一样,点击右侧的小按钮即可

OK,看到这里,有没有觉得可以解放自己的一部分劳动力了,很多需要来回点击输入看log的重复性工作被解放了

Cool😄...

有木有?

Conclusions(啰嗦)

通过上面的简单示例,你已经知道如何测试了,那么在写测试代码的时候,请尽量遵循以下几条:

• 测试方法一定要以test作为开头前缀
• 最好是一个模块开一个Test Case,毕竟业务是分离的
• 如果你已经准备好使用测试框架,那么就认真实践TDD(Test - Driver Development)
• 尽量使用单条测试,因为Command + U会执行你所有的测试

测试代码是必要的,可能很多同学都会在各类博客看过或听说过TDD(Test - Driver Development),测试驱动开发在一定程度上可以保证代码的质量,同时保证交付的效果如预期.

当然辣,现实是,很多开发同学不写测试代码,楼主曾经见过不但不写测试,连手动测试都不做的开发者,甚是可怕;而且,超自信,当bug出现的时候,信誓旦旦的说:一定是后台的问题,我的代码是不会有bug的😥

本文只是一个引子,带你简单感受一下测试的强大,至于测不测...

生命不息，折腾不止...
I'm not a real coder, but i love it so much!