一点个人理解

首先是做不做单元测试，个人感觉是要做的，这个其实是一个省时间的过程；并且是一次处理，长期受益的过程，可能需要自己尝试一下会更有体会，只是单纯的讲理论可能大家会有不同意见。
既然要做，怎么做，首先有些测试原则，有些测试点，有些测试方法这些东西可以有助于我们更好的做好单元测试。
另外一个点，单元测试其实有助于改善我们的代码设计，当一个重要的功能很难去做单元测试时，往往是我们代码设计不够合理。举个例子，在接触的各种情况中，目前碰到的一个类不太适合进行单元测试的话，目前看到的原因可能包括，对外函数比较少，然后是整个流程过长，这个应该需要进行分解，一是代码可以更简洁，而是如果流程过长，真要出问题，找错误也比较费劲，所有最好是单个流程都能进行单元测试，这样的话，应该代码和设计都会比较合理。

随手记

我们需要确认在任何情况下，这段代码运行的结果都符合我们的预期
保证所有的测试通过，避免添加新功能引入了新的bug

6个值得测试的具体部位：Right－BICEPRight：结果是否正确，这个应该没啥异议
B：是否所有的边界条件都是正确的
I：能查下反向关联嘛
C：能使用其他手段交叉检查一下结果嘛
E：是否可以强制错误条件发生
P：能否满足性能要求
边界条件：
1:完全伪造或者不一致的输入数据
2:格式错误的数据
3:空值或者不完整的数据
4:如果不允许重复的list，传人重复的
5:如果有序的list，传入无序的
6:打乱流程顺序，比方说正常流程先登陆，再付款，可以先付款再登录
检查反向关联：
对于一些方法来说，我们可以利用反向的逻辑关系来验证他们
例如如果功能是求一个数字的平方根，可以求平方根的平方来进行验证，例如数据库的插入操作可以使用查询操作来，但是如果反向关联的两个方法都是我们来实现的，就需要注意一下两个都有问题结果错误被掩盖的问题。因此类似求平方这个函数可以用两个数来相乘、查询函数可以系统原生的函数
交叉验证：
例如对于某一个功能有不同算法，因为效率和性能原因，我们选择了A算法，那么进行验证的时候，可以来使用B算法，获取结果与A算法的结果进行对比
还有一个办法是使用类不同的部分来做，例如图书馆系统中，图书总量是不变的，那么借出去的书加上目前图书馆里躺着的数量等于总藏书量
强制产生错误条件
可以通过Mock对象来干这些事，
一些能想到的环境方面的要素：
1内存耗光
2:磁盘满了
3:时钟出问题
4:网络不可用或者出问题
5：系统过载
。。。
性能特性：
主要设定一个大体的范围来判断，例如做一个性能的压力测试，比方说数据库插入效率，插入10000条数据需要满足4S完成，这样重构操作时候，可以保证如果出了性能问题，这个会不过
CORRECT边界条件：
1:一致性：值是否符合预期的格式
2:有序性：一组值是该有序的还是无序的
3:区间性：值是否在一个合理的最大值和最小值的范围之内
4:引用：耦合性－代码是否引用了一些不受代码本身直接控制的外部因素
5:存在性：值是否存在（例如非零、非空、包含于某个集合等）
6:基数性：是否恰好有足够的值
7:时间性：所有事情是否都是按顺序发生的，是否在正确的时间、是否及时
一致性
就是考虑输入非法的情况，比分说文件缺头少尾
有序性
就是比分说你写了一个程序如果依赖顺序，如果不按顺序给会怎样，如果边界值在第一个、最后一个、中间会怎样，用户都希望程序会更加灵活，适配各种情况
区间性
将值控制在一定的区间范围内，例如旋转角度会是0-360，其他的数需要处理或者抛异常
引用和耦合性
有时候我们的程序依赖外部条件，需要测试外部条件不满足情况下，我们程序的运行情况，比方说转账依赖，用户已经登录，如果没有登录转账会是什么情况
存在性
比方说文件不存在，数据库不存在情况下程序的表现如何
基数性
比方说如果满10个出报表，那一个怎么出，没有怎么出，多余十个怎么出
时间性
相对时间、绝对时间、并发情况

Mock对象
真实对象有几个不太好处理的点，包括：
1:真实对象具有不可确定的行为（例如股票行情）
2:真实对象很难被创建
3:真实对象很难被触发（比方说网络错误）
4:真实对象有（或者是）界面相关的东西
5:测试需要询问真实对象它是如何被调用的（例如，测试可能需要验证某个回调函数是否被调用了）
6:真实对象实际上并不存在（比方说第三方提供，与新硬件打交道）
使用Mock可以比较好的解决这个问题，并且实现Mock对象主要有三个方面
1:使用一个接口来描述这个对象
2:为产品代码实现这个接口
3:以测试为目的，在mock对象中实现这个接口
好的测试应该具有以下的品质：
自动化
彻底的
可重复
独立的
专业的
自动化
指的是测试自动化和检查结果自动化，对于测试需要的任何条件，都应该让它们成为测试自身的一个自动化组成
彻底的
单元测试覆盖率的问题，一个极端是覆盖所有case，但是可以考虑对所有边界进行测试
可重复
每个测试应该是独立于其他测试的，而且必须独立于周围的环境，想能达到的目标是测试应该能以任意顺序一次一次的运行，并且产生相同的结果
独立的
简单理解为一个测试函数对一个一个函数或者一个复杂函数的一部分，达到的效果是，哪个case挂了，能明确的知道是什么原因，哪个逻辑出了问题
专业的
意思就是测试代码也要好好写，也要符合各种设计，跟对外产品相似
面向测试的设计
利用单元测试能够提高改善代码设计和架构的机会
1:通过使用面向测试的设计方法，更好地分离关注点
2:通过定义类的不变性更好的阐述设计意图
3:通过使用测试驱动的设计方法，改善接口的设计
4:确立和局部化验证的责任

通过有意的设计出方便测试的代码，你可以让代码有更好的结构和可维护性。如果测试代码并不那么显而易见，或者测试代码看起来写的非常丑陋，甚至难以编写的话，那么应该暗示着设计可能需要修改，个人想法，对于那些感觉比较容易出问题的地方，如果感觉不能很好的写测试代码，应该就需要对代码进行重构，重新考虑下整体设计，是不是这段代码可以分离出来，更好的测试，然后考虑下这样的类设计是不是也是更加合理的
测试类的不变性
有些类理论上对外的一些表现应该是一致的，可以理解为在任何场景下对一些东西进行断言应该永远是正确的，例如一个有序队列，在增删改差之后都会是有序的，这样的话可以在每个操作之后都去对有序性进行验证，还有类似借贷必须平衡，类似这些
测试驱动设计
通过写测试代码，作为类的用户找到写起来不太靠谱的地方，这样可以去修改设计，来让类和设计更合理
检查无效参数
一定程度上要确认由谁来负责做数据的校验，将无用的数据干死

大家对于文章内容，有疑问或者希望有内容补充修改的可以在评论中提，笔者会秉承互联网产品哲学，小步快跑，快速迭代，不断修改和优化文章内容。