翻译于国外收费教程，如果有不对请指正
Test Development Cycle
讨论Test Driven Development的标准流程时，列了如下几点：
- 为想要实现的功能写一个test
- 检查一下，这个test失败了
- 实现代码来满足这个test
- 重复上述过程
过程很简单，但当你头一次创建项目，想要开始写第一个测试的时候，却又没有任何头绪。我要先build啥呢？我要写什么test呢？怎样为一个还不存在的东西写test呢？
通常，可以从一个我们想要实现的指定需求开始。然后走如下的流程:
- 为一些指定的需求写一个e2e test
- 检查这个e2e test 失败了
- 基于这个e2e test的失败信息，决定为了通过测试需要实现什么功能
- 为3中决定要实现的功能写一个单元测试
- 检查一下unit test失败了
- 实现代码来通过unit test
- 检查一下此时e2e test通过了没
- 如果e2e测试通过了，回到第1步。如果没通过，回到第3步
当构建你的APP时，持续的走这个流程。你的需求决定了你的e2e test, 同时e2e test又决定了unit test。努力让unit test通过，最终e2e test也会通过。一般来说，在e2e test通过之前你需要通过多个不同的unit test（注意，因为e2e test是同时test多个组件，每个组件都有各自的uinit test）。
上述的流程获取已经让你明白了不少，但有可能你还会好奇如何精确地为不存在的东西写一个test。最简单的想法就是—写出你期望他们如何工作的测试。 如果我正在写一个关于doSomething方法的 unit test，就像它已经存在一样，然后我在我的test中调用它。当然，如果不存在，test跑起来的时候就会报错，这些错误会让我们知道，为了通过test，哪些功能需要实现。
Deciding What to Test First
当非要指出要先test什么时，会有点儿尴尬，尤其当你是个testing新手。通常，我喜欢会列出所有我想要创建的e2e test（比如app的需求），然后选择最接近app核心的test。想一下我们将要构建的app的需求，并列下来，然后我来更深入地讲解选择的标准。举个栗子：
- 用户可以看到课程模块列表
- 选择一个模块后，用户可以看到可用课程的列表
- 选择一个课程后，用户可以看到这个课程的内容
- 一个用户只能用合法的license key来登录app
- 没有登录时，直接显示登录视图给用户
这些需求没有特定的顺序。这个课程软件的核心—展示课程给用户，所以考虑如下需求：
- 一个用户只能用合法的license key来登录app
用户首先要做的是登录到app，但是与app的核心功能并没有半毛钱关系。访问控制在任何类型的app中都会有，也是我们偏向于稍后处理的东西。
一下的需求与核心功能相关性更强些：
- 用户可以看到课程模块列表
- 选择一个模块后，用户可以看到可用课程的列表
- 选择一个课程后，用户可以看到这个课程的内容
这些需求关系到呈现课程列表给用户。第一步就是显示课程模块列表给用户，因此首先test它是很有必要的。
最后，你选择优先test什么并不重要。重要的是不要被这个决定阻碍，如果你不确定先选哪个好，就随便挑一个吧。
