在移动开发的过程中，编写测试代码已经不再流行，相反的，人们可能为了提高开发效率，尽量避免测试代码的编写以节约时间。作为开发菜鸟，我尝到了单元测试的好处： 不仅能保证您的代码能如预期运行，还能保护代码以防被其他小伙伴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上下载完整的源代码。
