从单元测试开始说起

编程从一个角度来说，象是在推土，或者设定个小目标，完成，再设定一个小目标再完成，每一小步都有成功的喜悦。是在做一个类似一小步，一小步创作的东西，每一步有小成果，有它的趣味性和创造性，有每次一个小胜利的喜悦。编程的过程从一个角度来说更象是扫雷，每次一小步，还要保证扫过的地方一定没有雷，有它的谨慎性。

 

总的来说程序可以分为衔接部分和功能部分。功能程序要要有单元测试来保证。集成测试来保证衔接部分和单元协作的正确性。

面向过程和面向对象和分合的关系：分合角度，面向过程主合A->B->C,面向对象主分分为ABC三对象；组件角度，面向过程和衔接程序相呼应，面向对象和功能程序相对应。面向过程和面向对象的分合还体现在《对象内的平行方法》,还有一个方面是分合及过程对象和对象的粒度有关系，对象内部实现肯定是过程，但过程当中要不要再抽出些对象则取决于业务粒度复杂度的取舍。总结一句话：面向过程和面向对象在一定程序上是分合粒度的产物。

 

简单和复杂

先考虑程序的复杂性，如果很简单，类比一些管组成的水管道，每个管功能都很单一，只要水流通过，不漏水就可以，这时可以依靠组装好后直接集成测试就可以。但如果是个汽车（是拿没有汽车的时间做个汽车设计来类比，因为程序设计时本程序是不存在的，是创造的过程），则要先分析出主要的功能部件，产生动力的部件起名发动机，可以暗送具体跑的部分命名为轮子，还有怎么把它们衔接起来，每个部件要分析输入和输出，要有单元测试来保证每个部件的正确性，要有集成测试来保证协作和衔接程序的正确性。

 

分析过程

第一部定义好程序是否是复杂程序后，如果是复杂程序，就要进行衔接部分和功能部分的切分设计，功能程序部分的分析方法很重要的就是输入和输出（输入和输出要通过是否概念是否有重合关系抽象出最核心无重复的输入输出元素），有一个要考虑的就是功能程序单元是否要有状态，个人更倾向于状态让衔接程序来持有，功能程序无状态，只集中处理业务逻辑，清晰，可以方便的进行单元测试。

 

可自测代码

可自测代码关注代码是可以自己测试自己的正确性，但并不关注先写测试还是先写代码。

 

Mock不仅仅是Mock一个对象，可以提供基于行为的测试。

 

示例：

录制系统按照规则（0-16,16-24）进行录制和停止录制。

step1:复杂应用

setp2:衔接程序：持有状态（正在录制的信息）。功能程序：录制服务，输入：规则，状态，时间。输出：根据规则进行新录制和停止录制，并返回录制信息及停止录信息。

setp3:单元测试及开发，录制服务因为依赖其它系统进行录制，可以进行mock测试。   

 

特别关注测试，模式给出了一些好的经验，但测试确让程序必须要好，我觉得测试更实际，使用测试来强迫程序必须松耦合，再在重构的过程中使用一些好的模式来避免重复如《对象内的平行方法》。

 

时间紧时更关心集成测试。

转载于:https://www.cnblogs.com/guanpanpan/p/3414295.html