单元测试编写体会

 今天尝到了单元测试的甜头，以前对单元测试有偏见，觉得它是代码编写工作中的负担，现在看来，我应该呈清一下。

首先，单元测试不是业务逻辑测试，它的测试对象应该是（但不限于）一个很简单的功能。说道简单功能，我想我有必要再深入一下我这里指的简单功能到底是什么。

我们可以分析一下我们写过的代码，不难发现我们的代码可以大致分为（但不限于）两种：一种为业务逻辑代码；一种为和业务逻辑完全没有关系的功能代码。例如：计算打折的代码属于业务逻辑代码，但是如果在打折过程中，有将打折数据从datarow转换为实体对象的代码，这部分代码实际上实现的是一个数据转换功能，和业务逻辑没有任何关系，在系统中处于最底层，在开发周期中处于最前端，在逻辑上又最单纯，这部分代码就是我所指的功能代码。有的时候，我觉得程序执行的过程实际上就是数据转换的过程，或是将数据的物理形态由一种形式转换为另外一种形式；或是将数据的逻辑形态由一种形式转换为另外一种形式。而前者，大多是我所指的简单功能，这才是单元测试的对象。

周五的时候，我和以前一个做医院系统的朋友讨论了一下工作中遇到的问题，在谈话中，我感觉到后来也认为确实是这样：那些简单功能的代码一般处于系统的底层。这是一个事实，在系统最后进行组装测试的时候，由于底层产生的问题，会由于系统当前的复杂度而被放大（其程度是不可估量的，就要看编写代码的那个人的经验了，甚至要看运气了。说实话，写到这里，我觉得“运气”二字很恰当，确实在实际的工作中，在最后运行代码的时候，我也带有这样的心理：希望有好的运气，不要有难缠的bug出现。）。

正如我们头推荐的那本书里说的那样，单元测试的目的是为了保证每一个已有的功能是正确的。当每一个简单的功能都是正确的，那么将它们组合起来，组合的结果会是错误的吗？（呵呵，这是一个很有意思的逻辑问题）

而以前我认为，单元测试就是要去测试那些很复杂的逻辑模块的接口，虽然至今我还不敢断定我的这种认识是否是正确的，但是我体会过，要用单元测试来测试这样的模块的结果是你要付出很大的代价，最终让你对单元测试望而却步。

回到对代码的分类，实际上当我想到将代码分为业务逻辑代码和简单功能代码的时候，我就认定，简单功能代码是单元测试的对象。自己也就是在这样的实践中，让我从新认识了单元测试。

其实单元测试的效用还不仅如此，如果你的系统设计中存在软肋，可以针对它编写专门的单元测试（这也许是用工程管理来平衡工程设计的一个例子）

发现单元测试的过程，实际上也是发现代码价值，认清代码本质的过程，讨论单元测试，应该更（但不限于）加关注单元测试的对象，至少目前我是这样认为的。

希望各位 高手多多指教。