iOS APP iOS Test-Driven Development by Tutorials free section 学习笔记-前言与概述

tags: TDD day

前言

上週参加iOS Developer 高雄小聚，有聊到 Rxswift 的学习方法。Rxswift 学习是有一定的难度与门槛的，所以我在学习上撞得满头包，因此我放慢自己的步调，梳理一下如何达到学习RxSwift。

为什么要学 unit test?

事实上我在学习 Rswift的过程中碰壁了，我们都知道Rxswift 可以有效防止 Callback hell。

学习上的难点，知其然而不知其所以然

但是我的对于 Callback hell的感受不够深刻，这是因为 "Rxswift 解决的问题" 是二手资讯，并不是我亲自解决的。也就是说我知道了解决问题的方法却不知道问题本身。这成为了我学习的阻碍。

所以我学习TDD？

为了学习Rxswift而学习TDD或许是绕道，但是为了让自己最快到达高内聚低耦合的目标，学习 TDD 是不错的方法。

让程式码 testability

因为 TDD 这个 software process，会帮助我们思考如何让测试目标有 testability，因此在开发过程中会把程式拆的很细。

体会设计架构的意义

将程式码职责分离，在分离到极致的过程中，不难发现程式码会趋向现在流行的设计架构。这帮助我们在学习上，更容易体会设计架构的意义。

因此我决定了解TDD的开发流程，并实际开发一个简易的App。小聚时，有位资深工程师推荐了一本书：

连结

What Is TDD?

TDD 是 Test-driven development 的缩写，他是一种迭代开发软体的方法。

图片来源

这边必须要特别注意“迭代”这两个字的意义。

TDD有四个steps:

Write a failing test 写一个会失败的测试Make the test pass 通过测试Refactor 重构Repeat 重複

在使用 TDD 你必须非常清楚

良好的测试可确保您的应用按预期运行。但是，并非所有测试都“good”。为进行测试而编写测试不是一个值得的练习。相反，好的测试是失败的，可重複的，快速的运行和可维护的。

正确的 TTD 测试守则：

1. 写一个 failing test

第一步是编写一个失败的测试。根据定义，这证明测试是失败的。不能失败的测试不是很有用。相反，它们浪费了宝贵的CPU time。

2. 在允许您编写新测试之前，所有其他先前的测试都必须通过

在允许您编写新测试之前，所有其他先前的测试都必须通过。这样可以确保您的测试是可重複的：您不只是运行您正在处理的单个测试，而是不断地运行所有测试。

3. 测试时间最好是一秒钟或更短的时间

通过频繁运行每个测试。您的所有测试都需要几秒钟的时间-最好是一秒钟或更短的时间。

4. 每一次refactor同时更新生产和测试代码

重构时，您将同时更新生产和测试代码。这样可以确保您的测试得到维护：您一直在不断更新它们。

5. 必须遵守流程

通过并行并行编写生产代码和测试，可以确保代码可测试。如果您要在完成代码后编写测试，那么生产代码很可能需要大量重构才能进行完全的单元测试。

你该测试的对象是什么？什么不该测试？

更好的测试覆盖率并不总是意味着您的应用程序会得到更好的测试。有些事情应该测试，而其他则不应该。
我们需要秉持的四不原则：

做代码写入测试，不能以自动化方式捕获，否则。这包括类的方法中的代码，自定义getter和setter以及您自己编写的大多数其他代码。不要为生成的代码编写测试。例如，为生成的getter和setter编写测试是不值得的。Swift可以很好地做到这一点，您可以相信它的工作原理。不要针对编译器可能捕获的问题编写测试。如果经过测试的问题会产生错误或警告，Xcode会为您抓住它。不要为依赖代码编写测试，例如您的应用程序使用的第一方或第三方框架。框架作者负责编写这些测试。例如，您不应该为UIKit类编写测试，因为UIKit开发人员负责编写这些测试。但是，您应该为其自定义子类编写测试：这是您的自定义代码，因此您有责任编写测试。

总结

TDD的最令人诟病的地方是它花费的时间太长。但是，事实是，与根本不编写任何测试相比，他花费的时间更少。
开发的实时成本不仅仅是编写初始的第一版生产代码。它还包括随着时间的推移添加新功能，修改现有代码，修复错误等。从长远来看，遵循TDD所花的时间要比不遵循它要少得多，因为它产生的代码更具可维护性，而且错误更少。

实作过程