一、前言
在之前的单元测试的过程中，由于对单元测试的概念没有足够的理解，所以舍本逐末，造成了把单元测试和集成测试混淆的错误做法，所以我周末在家阅读了相关的书籍和文档，才对单元测试测试初步的认识，以下我讲解的将会是iOS和Android的共同部分，由于我不懂Java，所以就不细节阐述了。
二、概念
单元测试是指对软件系统中最小可测试单元进行的检查和验证。所谓的单元，需要根据实际情况去判断，一般指的是功能不可再分的模块或者函数。（对类和方法的测试）
集成测试是单元测试的逻辑扩展，最简单的形式是把两个已经测试过的单元测试组合成一个组件，并测试他们之间的接口。在软件开发中，集成测试可以简单的分为API接口测试和功能集成测试。API接口测试是指程序以网络请求的方式使用到了后台服务的功能，测试时需要验证网络的请求以及相应是否符合预期。功能集成测试其实就是功能的测试。
三、框架
单元测试比较流行的框架有两种：测试驱动开发（TDD，Test Driven Development）和行为驱动开发（BDD，Behavior Driven Development）。
测试驱动开发是一种测试先于编写代码的思想，用于指导软件开发。举个例子来说明，TDD就像是在砌墙之前的一条辅助的拉线，根据这条辅助的拉线来判断墙是否砌的平稳，如果墙砌好了之后再来测量是否平稳，那就免不了的需要各种重修了。所以这种框架现在不适合我们的项目。
行为驱动开发是一种敏捷软件开发的技术，是TDD的一种延伸，通过Given-When-Then三个流程化的条件来帮助开发确定应该测试什么。
这种方式有什么优势呢？举个例子，以前的模式可能是市场业务人员发现一个问题，然后转述给产品经理或者测试，然后再转述给开发人员，开发人员根据这个特征来还原这个问题，写成一个测试用例，但是在转述中间过程中很可能就丢失了关键的部分，所以是不严谨的。
但是BDD就像是讲故事一样，最一开始这个需求的提出者根据Given-When-Then的流程化描述清楚这个问题，把用户或者客户真正的通过Feature文件联系在一起了，其沟通是顺畅的，QA，PM，开发，测试，客户，用户可以通过这一媒介，进行高效无障碍的沟通。
根据我们现在开发的现状，肯定是选择BDD框架。
四、方法
4.1、测试方法
我们可以根据Given-When-Then模式来组织我们的测试，把测试拆分为三个部分。
given：通过创建模型对象或者将被测试的系统设置到指定的状态，来设定测试环境。
when：这部分包含了我们要测试的代码，一般情况下这里只有一个方法调用。
then：我们需要检查我们行为的结果。
4.2、可重用代码
随时单元测试的用例的增多，测试中重复的代码也会也来越多，我们需要把代码片段整理出来，加入到一个公共类中，为所有的测试用例服务。
4.3、Mock
Mock测试：就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。
我们不应该过度mock，在适当的情况下，可以使用真实对象来保证正确性。
但是在Mock的时候我们无法保证这个Mock的正确性，所以我们在Mock结束之后，应该去验证这个Mock的正确性。
4.4、验证
被单元测试的对象或者系统，我们简称为SUT（System Under Test，被测试系统），SUT大致可以分为三种：
- 有明确的返回值，通过返回值判断是否符合预期，这种方法被称为返回值验证法。
- 没有返回值，但是这个方法会改变其对象内部的一些属性或者状态，这种方法被称为状态验证法。
- 依赖于外部的一个类或者方法，它会调用外部的一个 方法，被称为行为验证法。（比如代理回调函数）
五、结语
测试中需要注意的点：
- 不需要测试私有方法。
- 不需要测试构造函数，因为构造函数不应该包含行为，所以没有值得测试的东西。
- 不要Stub私有方法和外部库。
备注
BDD中也有很多种的选择方案：
- XCTest + OCMock（iOS）、JUnit + Mocktio（Android）
- Kiwi（自带mock）
