要完成所有的单元测试的任务了，做了将近三个月的时间，如果放在以前我有一肚子苦水要述说，不过经历了一些思想上的洗礼之后，不在那么单纯，只为把手头工作做的更加出色而已！

　　这是单元测试后一篇了，来做个总结把！

　　目录：

　　好的单元测试应该具有的特点
　　单元测试的命名规范
　　建立自己的公共调用库
　　单元测试带给我的思考和感悟
　　总结图示

　　1、好的单元测试应该具备的特点

　　一个好的单元测试一定有它具备的特点，下面来说说那些主要的特点！

　　主要概括为 → A-TRIP原则：

　　自动化　　→ Automatic

　　彻底性　　→ Thorough

　　可重复性   → Repeatable

　　独立性　　→ Indepentdent

　　专业性　　→ Professional

　　恰到好处的单元测试会使你的工作轻松，代码整洁干净，乱用，没有准则的用会浪费你大量的时间，不但没有效果还会是工期延误，所有了解单元测试很重要！

　　① 自动化

　　　　a）不需要人的参与，有的时候只是轻轻的点击一个按钮能自动执行，所以自动化的标志是不能比点击一个按钮的过程还要复杂！

　　　　b）在签入其它的测试代码时不能对现有的代码造成影响！

　　　　c）能够自动识别测试是失败还是成功（VS2008以后的版本都集成了这个功能）！

　　　　d）在任何时候，任何地方都能自动运行（所以“Moles”技术是关键）！

　　核心：执行测试代码和检查测试结果都必须自动化（VS2008以后版本都实现这个功能了）！

　　总结：I，不要引入一个由于需要手动步骤而打破单元测试的自动化模型的测试！

　　　　　II，对于测试所需要的任何条件（大部分是数据库）都应该让它成为自动化测试的一部分，如果有需要可以使用Mole技术！

　　② 彻底性

　　　　所谓的彻底性是说你的测试案例必须要考虑的全面，应该把可能出现的问题都做成测试案例！

　　　　具体从哪些方面着手，可以参阅这篇：走进单元测试：测试需要从哪些方面着手
　　③ 可重复性

　　　　a）每个测试案例应该独立于所有的其它测试，而且必须独立于周围的（系统）环境！

　　　　b）测试代码能够一次又一次的运行，在不修改代码的前提下都能产生一样的结果，否则有BUG！

　　　　c）不要把测试代码写死，应该写的更加灵活一点，运用封装，重构等等的思想！

　　　　d）不要让测试本身也出现BUG，确保测试代码的正确性！

　　④ 独立的

　　　　a）每个测试应该有很强的针对性，也说一个测试只能测试一个方面的内容！

　　　　b）每个测试应该独立于环境（软件所处的系统环境）和其它测试！

　　总结：I，每个测试都不能够依赖于其它测试，你可以在任何时间运行这个测试而不受其它测试的影响，每一个测试都应该是一座孤岛！

　　　　  II，所以测试一个函数都有很多个测试方法，只有这样才是真正的测试！

　　⑤ 专业的

　　　　a）所谓的专业是你的测试代码应该跟你的开发代码保持一样的风格，如：简洁明了，封装，解耦，不要出现“Hard Core”，要灵活一点！

　　　　b）拒绝编写冗余的测试代码，千万要小心不要掉进这个陷阱，因为像我们这样的新手在初期都不会注意到这样的问题，所以我们要牢记在心里！

　　　　c）遵循普遍规则：1.维护封装 2.降低耦合！

　　总结：不管怎么样你都应该认认真真的对待单元测试，代码的质量要求都应该跟开发代码同等水平，这是作为开发者必备的素质！

　　2、单元测试的命名规范

　　在我们项目的中，可能需要测试的方法有成千上百个，而每一个测试方法都有可能写三个以上的测试案例，那么怎么来维护这么测试案例呢？

　　所以我们应该规范方法的命名方式，那么其他人在阅读你的测试代码时，直接通过方法名能知道你的测试案例是测试哪个方面的了！

　　Note：单元测试案例类似于一个可执行文档，可以帮助其它的开发人员了解方法的作用！

　　在我们的项目中是这样规定的：方法名 + _ + 你测试是哪个方面的内容 + _ + 产生的结果！

　　下面我举个列子，下面的测试方法命名是针对这个函数来命名的，如：