软件界有一句俗语：“开发人员不应该测试他们自己的代码”。这是因为开发人员对自己的代码了如指掌，他们很清楚如何采用适当的方法对代码进行测试。尽管这 句俗语很有道理，但却忽略了非常重要的一点 - 如果开发人员不对自己的代码进行测试，又如何知道代码能否按照预期的方式运行？

    简单说来，他们根本无从得知。开发人员编写那种运行不正常或只在某些情况下运行正常的代码是一个严重的问题。他们通常只测试代码能否在很少的情况下正常运行，而不是验证代码能够在所有情况下均正常运行。

    发现软件错误的情况有很多：

    1.由首次编写代码的开发人员发现。
    2.由尝试运行代码的开发人员发现。
    3.由组中的其他开发人员或测试人员发现。
    4.作为产品大规模测试的一部分。
    5.由最终用户发现。

    如果在第一种情况下发现软件错误，则修复错误比较容易，成本也很低。情况越靠后，修复软件错误的成本就越高；修复一个由最终用户发现的软件错误可能要耗费 100 或 1000 倍的成本。更不用说用户通常因为软件错误导致工作无法继续，而一直等到下一个版本才能解决问题。
    如果开发人员能够在编写代码期间发现所有的软件错误，那就再好不过了。为此，您必须编写能在编写代码时运行的测试。

    测试是软件开发的重要环节之一。按照软件开发的过程测试可分为：单元测试、功能测试、性能测试、性能测试、集成测试、系统测试、域测试（Field test）等。我们这里将主要研究的是面向程序员的单元测试。

    什么是单元测试

    单元测试是开发者编写的一小段代码，用于检验被测代码中的一个很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特 定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。

    单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。

    为什么要使用单元测试

    我们编写代码时，一定会反复调试保证它能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的客户。但代码通过编译，只是说明了它的语法正确；我们却无法保证它的语义也一定正确，没有任何人可以轻易承诺这段代码的行为一定是正确的。

    幸运，单元测试会为我们的承诺做保证。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。

    单元测试有下面的这些优点：

    1、它是一种验证行为。

    程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支缓。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障。这样，我们就可以更自由的对程序进行改进。

    2、它是一种设计行为。

    编写单元测试将使我们从调用者观察、思考。特别是先写测试（test-first），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。

    3、它是一种编写文档的行为。

    单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。

    4、它具有回归性。

    如果要给单元测试定义一个明确的范畴，指出哪些功能是属于单元测试，这似乎很难。但下面讨论的四个问题，基本上可以说明单元测试的范畴，单元测试所要做的工作。

    1、 它的行为和我期望的一致吗？

    这是单元测试最根本的目的，我们就是用单元测试的代码来证明它所做的就是我们所期望的。

    2、 它的行为一直和我期望的一致吗？

    编写单元测试，如果只测试代码的一条正确路径，让它正确走一遍，并不算是真正的完成。软件开发是一个项复杂的工程，在测试某段代码的行为是否和你的期望一 致时，你需要确认：在任何情况下，这段代码是否都和你的期望一致；譬如参数很可疑、硬盘没有剩余空间、缓冲区溢出、网络掉线的时候。

    3、 我可以依赖单元测试吗？

    不能依赖的代码是没有多大用处的。既然单元测试是用来保证代码的正确性，那么单元测试也一定要值得依赖。

    4、 单元测试说明我的意图了吗？

    单元测试能够帮我们充分了解代码的用法，从效果上而言，单元测试就像是能执行的文档，说明了在你用各种条件调用代码时，你所能期望这段代码完成的功能。

    不写测试的借口

    到这里，我们已经知道了使用单元测试的种种理由。但目前的实际情况是大多数程序员不进行单元测试，或只进行简单的单元测试。下面是一些他们常用的接口：

    1、 编写单元测试太花时间了。

    我们知道，在开发时越早发现BUG，就能节省更多的时间，降低更多的风险。如果你仍然认为在编写产品代码的时候，还是没有时间编写测试代码，那么请先考虑下面这些问题：

    1）、对于所编写的代码，你在调试上面花了多少时间。
    2）、对于以前你自认为正确的代码，而实际上这些代码却存在重大的bug，你花了多少时间在重新确认这些代码上面。
    3）、对于一个别人报告的bug，你花了多少时间才找出导致这个bug 的源码位置。
    回答完这些问题，你一定不再以“太花时间”作为拒绝单元测试的借口。

    2、 运行测试的时间太长了。

    合适的测试是不会让这种情况发生的。实际上，大多数测试的执行都是非常快的，因此你在几秒之内就可以运行成千上万个测试。但是有时某些测试会花费很长的时间。这时，需要把这些耗时的测试和其他测试分开。通常可以每天运行这种测试一次，或者几天一次。

    3、 测试代码并不是我的工作。

    你的工作就是保证代码能够正确的完成你的行为，恰恰相反，测试代码正是你不可缺少的工作。

    4、 我并不清楚代码的行为，所以也就无从测试。

    如果你实在不清楚代码的行为，那么估计现在并不是编码的时候。如果你并不知道代码的行为，那么你又如何知道你编写的代码是正确的呢?

    5、 但是这些代码都能够编译通过。

    我们前面已经说过，代码通过编译只是验证它的语法通过。但并不能保证它的行为就一定正确。

    6、 公司请我来是为了写代码，而不是写测试。

    公司付给你薪水是为了让你编写产品代码，而单元测试大体上是一个工具，是一个和编辑器、开发环境、编译器等处于同一位置的工具。

    7、 如果我让测试员或者QA（Quality Assurance）人员没有工作，那么我会觉得很内疚。

    你并不需要担心这些。请记住，我们在此只是谈论单元测试，而它只是一种针对源码的、低层次的，为程序员而设计的测试。在整个项目中，还有其他的很多测试需要这些人来完成，如：功能测试、验收测试、性能测试、环境测试、有效性测试、正确性测试、正规分析等等。

    8、 我的公司并不会让我在真实系统中运行单元测试。

    我们所讨论的只是针对开发者的单元测试。也就是说，如果你可以在其他的环境下（例如在正式的产品系统中）运行这些测试的话，那么它们就不再是单元测试，而是其他类型的测试了。实际上，你可以在你的本机运行单元测试，使用你自己的数据库。

    总而言之，单元测试会让我们的开发工作变得更加轻松，让我们对自己的代码更加自信。无论是大型项目还是小型项目，无论是时间紧迫的项目还是时间宽裕的项目，只要代码不是一次写完永不改动，编写单元测试就一定超值，它已成为我们编码不可缺少的一部分。

其他相关资料

Unit testing

BeanUtils的copyProperties方法用来将orig中的成员变量的值复制给dest,即将已经存在的dest变为orig的副本。
    public void copyProperties(Object dest, Object orig) {
   .......
   }
      BeanUtils的populate方法用来将Map<Key,value>中的以值（String或String[]）转换到目标bean对应的属性中，Map中的Key是目标bean的属性名。
   public static void populate(Object bean, Map properties){
        ......
    }

copyProperties同样支持了populate中的功能（注apache的javadoc中,明确指明这个方法是为解析http请求参数特别定义和使用的,在正常的使用中不推荐使用.他们推荐使用BeanUtils.copyProperties方法）。

BeanUtils.copyProperties和populate的实现方法是将源bean（也可以是Map)中的每个element在转换器（Converter）的帮助下，将转换的结果设置到目标bean对应的属性中。例如在HTTP应用中需要从http request中抽取数据,http request传递过来的都是String 或是String数组类型的变量而目标类型可能是各种各样的，例如http request会有一个name=visitDate，value='2009-05-13'的参数，而目标bean 的visitDate属性的类型是java.util.Date。
       BeanUtils的copyProperties和populate需要在转换器(converter)的配合下实现源和目标对象之间的数据类型的转换。在BeanUtils.copyProperties的javadoc中说明的（Copy property values from the origin bean to the destination bean for all cases where the property names are the same—— 只要属性名相同就可以从源bean中拷贝值到目标bean中）这句话提供到功能就是要通过转换器才能实现的。在BeanUtils的copyProperties和populate的使用过程中Converter是一个非常重要的概念，它提供了强大的扩展能力。  
    /****************************************************************/
        public interface Converter {
           public Object convert(Class type, Object value);
        }
     /****************************************************************/    
    convert方法的参数type是目标转换的类型，参数value是被转换的值，返回值就是转换以后的结果。当有需要自定义或扩展的Converter 的时候可以通过注册自定义的转换器来实现，例如Beanutil自带的DateConverter不支持String到java.util.Date的转换，通过扩展DateConverter就可以实现支持。需要特别注意的是Converter 是注册在classloader一级的，也就是说在一个class loader中同一时间只能有一个转换器起作用（BeanUtils的copyProperties和populate会依据目标bean属性的类型来决定启用那个转换器），我之前的项目中就有因为其他模块中在特定的时候会重新注册了某个类型的转换器，而新注册的转换器又没有支持我所需要的转换，从而导致在我的模块中出现NPE。 所以在使用BeanUtils.populate和copyProperties的时候要注意以下几点：

1. 只在系统初始化的时候注册一个转换器，而不要在某个功能的执行过程中注册转换器。
       2. 转换器要能够支持项目各个模块的使用需求
       3. 谨慎使用或者思考一下BeanUtils.populate和copyProperties是你想要的方法吗？

在我使用BeanUtils.populate的模块中本意是实现bean和Map的属性拷贝并不需要类型和值的转换。至于说为什么会使用BeanUtils.populate完全是被它支持Map所误导，其实PropertyUtilsBean.copyProperties和 BeanUtils.copyProperties同样支持Map。就我想要实现的功能而言通过PropertyUtilsBean.copyProperties方法能更好地满足。PropertyUtilsBean.copyProperties方法不会有类型转换的逻辑，所以需要程序员自己保证目标和源Bean属性间的兼容性，也正因为如此PropertyUtilsBean.copyProperties的执行效率更高。

参考资料

BeanUtils.copyProperties与PropertyUtils.copyProperties用法及区别l

http://commons.apache.org/beanutils/v1.8.0/apidocs/org/apache/commons/beanutils/PropertyUtilsBean.html

http://commons.apache.org/beanutils/v1.8.0/apidocs/org/apache/commons/beanutils/BeanUtils.html

初用apache.commons.beanutils.BeanUtils