在移动开发的过程中,编写测试代码已经不再流行,相反的,人们可能为了提高开发效率,尽量避免测试代码的编写以节约时间。作为开发菜鸟,我尝到了单元测试的好处: 不仅能保证您的代码能如预期运行,还能保护代码以防被其他小伙伴wu'yi修改。单元测试与项目代码的结合,能帮助新人快速熟悉并接管您的项目。
TDD(Test-driven Development)
TDD 是一门艺术,他遵循以下规则:
- 写一个失败的测试
- 写少量代码通过测试
- 重构
- 重复直到满意 让我来看一个个简单的例子。 如以下实现:
func calculateAreaOfSquare(w: Int, h: Int) -> Double { }
复制代码
Test 1:
如果 w = 2
、h = 2
,那么我们期待的结果是 4
, 在这种情况下,单元测试一般会失败,因为我的的函数并没有实现 。那么下面我们稍微改一下:
func calculateAreaOfSquare(w: Int, h: Int) -> Double {
return w * h
}
复制代码
这样 Test 1 就能轻松通过了。
Test 2: 如果 w = -1
、h = -1
我们期待的结果是 0
, 如果还用当前的函数,单元测试也会失败,因为我们的函数返回的是 1
。我们再改一下:
func calculateAreaOfSquare(w: Int, h: Int) -> Double {
if w > 0 && h > 0 {
return w * h
}
return 0
}
复制代码
现在 Test 2 也通过了。
像这样我们进行测试穷举,直到考虑到所有的边缘问题,也就完全通过单元测试。 从当前我们的讨论可以看出,TDD
不仅能提高我们的代码质量还能帮我们考虑到很多边缘问题的处理,除此之外,在结对编程中,一个编写测试,另一个的代码则需通过单元测试,从而有效的进行项目的良性推进。
本文中您将了解到:
- 在项目中使用 TDD 的好处
- 了解
Quick & Nimble
的基本工作原理 - 使用
Quick & Nimble
进行UI
测试 - 使用
Quick & Nimble
进行单元测试
预备工作:
Xcode 8.3.3、 Swift 3.1 有一定的 swift
的开发经验
创建一个原始工程:
假设我们有一个任务-----开发一款展示电影海报的简单应用程序,创建一个名为 MyMovies
的工程,然后基于该工程进行单元测试。
import UIKit
class MoviesTableViewController: UITableViewController {
override func viewDidLoad() {
super.viewDidLoad()
}
// MARK: - Table view data source
override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
return 0
}
}
复制代码
进行数据填充:
类型枚举
enum Genre: Int {
case Animation
case Action
case None
}
复制代码
这个枚举用于识别我们的电影类型。
Movie 模型
struct Movie {
var title: String
var genre: Genre
}
复制代码
简单列一些我们的电影模型数据
class MoviesDataHelper {
static func getMovies() -> [Movie] {
return [
Movie(title: "The Emoji Movie", genre: .Animation),
Movie(title: "Logan", genre: .Action),
Movie(title: "Wonder Woman", genre: .Action),
Movie(title
: "Zootopia", genre: .Animation),
Movie(title: "The Baby Boss", genre: .Animation),
Movie(title: "Despicable Me 3", genre: .Animation),
Movie(title: "Spiderman: Homecoming", genre: .Action),
Movie(title: "Dunkirk", genre: .Animation)
]
}
}
复制代码
这个类能方便我们很快的返回一组数据 在这个阶段,我们没有执行任何 TDD
, 这只是我们的准备阶段。 接下来就是我们的主题了,Quick & Nimble!
Quick & Nimble
Quick
是为Swift
和Objective-C
设计的基于 XCTest
的测试框架,它提供了一个DSL
来编写非常类似于RSpec
的测试. Nimble
和 Quick
很方便的结合在一起使用,关于 Quick
的更多信息,请看这里
引入 Quick & Nimble :
这里我们使用 Carthage
来做包管理
#CartFile.private
github "Quick/Quick"
github "Quick/Nimble"
复制代码
CartFile.private 是我们用来管理依赖的,如果您对 Carthage
不是很了解,那么您可以先看看 这里
添加完依赖后确保您的项目如下:
开始 Test #1
我们首先来测试一下我们的数据与视图数目是否相符。 打开 MyMoviesTests
文件 ,移除 XCTest
, 导入 Quick, Nimble
首先确保我们的类是 QuickSpec
的子类,它也是原始 XCTestCase
的子类。 因为 Quick&Nimble
的底层仍然是 XCTest
。因此我们需要重写 spec()
import Quick
import Nimble
@testable import MyMovies
class MyMoviesTests: QuickSpec {
override func spec() {
}
}
复制代码
Test #1 – Expect Table View Rows Count = Movies Data Count
首先我们在 ViewController
里面引入 subject
import Quick
import Nimble
@testable import MyMovies
class MyMoviesTests: QuickSpec {
override func spec() {
var subject: MoviesTableViewController!
describe("MoviesTableViewControllerSpec") {
beforeEach {
subject = UIStoryboard(name: "Main", bundle: nil).instantiateViewController(withIdentifier: "MoviesTableViewController") as! MoviesTableViewController
_ = subject.view
}
}
}
}
复制代码
请注意,这里我们使用@testable
导入MyMovies
,这一行指定了我们将要测试的目标项目。 当我们将测试 ViewController
的视图层时,我们需要从storyboard
中获取一个实例。 describe
闭包声明了我们将要对 MoviesTableViewController
进行测试
context("when view is loaded") {
it("should have 8 movies loaded") {
expect(subject.tableView.numberOfRows(inSection: 0)).to(equal(8))
}
}
复制代码
你将会发现
MoviesTableViewController__when_view_is_loaded__should_have_8_movies_loaded] : expected to equal <8>, got <0>
Test Case '-[MyMoviesTests.MoviesTableViewControllerSpec MoviesTableViewController__when_view_is_loaded__should_have_8_movies_loaded]' failed (0.009 seconds).
复制代码
可以看出,刚刚的测试是没有通过的,这就是 TDD。
修复 Test #1
让我们看看 MoviesTableViewController
的数据是如何加载的,我们添加几行代码后再来运行测试看看
override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
return MoviesDataHelper.getMovies().count
}
override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "MovieCell")
return cell!
}
复制代码
恭喜您,通过了我们的测试。
Test #2
下面我们来一个 UI
测试。
context("Table View") {
var cell: UITableViewCell!
beforeEach {
cell = subject.tableView(subject.tableView, cellForRowAt: IndexPath(row: 0, section: 0))
}
it("should show movie title and genre") {
expect(cell.textLabel?.text).to(equal("The Emoji Movie"))
expect(cell.detailTextLabel?.text).to(equal("Animation"))
}
}
复制代码
运行测试
MoviesTableViewController__Table_View__should_show_movie_title_and_genre] : expected to equal <Animation>, got <Subtitle>
复制代码
失败了。我们修改一下在测试试。
struct Movie {
var title: String
var genre: Genre
func genreString() -> String {
switch genre {
case .Action:
return "Action"
case .Animation:
return "Animation"
default:
return "None"
}
}
}
复制代码
然后再修改一下 cellForRow
这个方法
override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "MovieCell")
let movie = MoviesDataHelper.getMovies()[indexPath.row]
cell?.textLabel?.text = movie.title
cell?.detailTextLabel?.text = movie.genreString()
return cell!
}
复制代码
Bingo, 又通过了一个测试,接着我们在优化一下:
class MoviesTableViewController: UITableViewController {
var movies: [Movie] {
return MoviesDataHelper.getMovies()
}
// MARK: - Table view data source
override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
return movies.count
}
override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "MovieCell")
let movie = movies[indexPath.row]
cell?.textLabel?.text = movie.title
cell?.detailTextLabel?.text = movie.genreString()
return cell!
}
}
复制代码
好了,至此一个简单的 TDD
过程结束了
总结
我们写了第一个测试来检查模型个数,它失败了。 修改了一下加载模型数据的逻辑,然后通过了。 我们写了第二个测试来检查UI
是否正确,失败了。 修改了一下UI
展示逻辑,然后通过。 然后,我们对代码做了一次重构,适当优化一下。 这就是TDD
的常见开发流程。 如果您有任何疑问,请留言。
您可以在 GitHub
上下载完整的源代码。