《单元测试,让我们编程更加美好》由会员分享，可在线阅读，更多相关《单元测试,让我们编程更加美好（5页珍藏版）》请在金锄头文库上搜索。
1、什么是单元测试什么是单元测试单元测试是在软件开发过程中要进行的最低级别的测试活动。它是一种细粒度测试。测的是独立的一个工作单元。对 java 应用程序中，独立的一个工作单元常常指一个方法（并不总是如此） ，一个工作单元就是一项任务，它不依赖于其他任何任务的完成。单元测试是基于 TDD（测试驱动开发，Test-Driven Development）的一种应用。测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明 确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编 写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完全部功能的开发。单元
2、测试的作用单元测试的作用1.确保代码的质量在每个工作单元编写就进行测试，可以验证代码和设计时的逻辑是否一致，防止出现 隐藏的错误，提高代码的质量。2.确保代码的可维护性只要我们的单元测试是正确的，那我们就可以保证无论你怎么修改那段代码，只要测 试通过，你修改的逻辑代码就是正确的。这为任何时候对代码重构带来了必要的保证。3.确保代码的可扩展性进行单元测试可以使每个成员的功能模块能更透明化，让代码之间的耦合度降到最低。4.提高时间效率单元测试虽然在直观上会增加编程中的工作量，减缓了代码的完成时间，但是如果忽 略单元测试会在完成代码后的集成测试和系统测试时，花费大量时间来跟踪和找寻存 在于每个独立的
3、工作模块中的缺陷。反而延迟了最终完成的时间。而一个 bug 被隐藏 的时间的越长，修复这个 bug 的代价就越大。单元测试的优点单元测试的优点1.它是一种验证行为。程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支缓。就算是 开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重 要的东西。而且它为代码的重构提供了保障。这样，我们就可以更自由的对程序进行改进。2.它是一种设计行为。编写单元测试将使我们从调用者观察、思考。特别是先写测试（test-first） ，迫使我们 把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。3.它是一种编写文档的行为
4、。单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可 编译、可运行的，并且它保持最新，永远与代码同步。4.它具有回归性。 自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测 试。为什么不进行单元测试？为什么不进行单元测试？1.编写单元测试，增加了工作负担，会延缓项目进度?程序员拒绝编写单元测试的最多理由。 “为了完成编码任务，没有足够的时间编写单元 测试。编写单元测试会导致不能按时完成编码任务,推迟项目进度”。事实上真的是这样的 吗？软件有着其特殊的生命周期，软件开发也具有特殊性。首先，我们需要提供给用户的至少是一个能运行的产品。绝对不能是一堆不
5、能运行的 和充满了异味的哑代码。只有能够运行的，满足客户需求的代码才是真正有用的代码。这 时代码就变成产品了。很多程序员只关注编写代码的完成时间，而乎略了调试代码，集成及修改和维护时间。如果没有单元测试，开发活动会是这样的情景。以一个 web 应用开发为例：业务代码编写完成-打包-发布到服务器-进行功能测试-发 现问题-修改代码-再打包如此循环。任何一个 web 程序员对于这种开发情景都不会感到陌生。往往不断的打包，发布，功 能测试的时间是代码编写的 10 倍以上。通过集成系统来发现程序的 bug，我们往往很难一 下子准确的定位 bug 产生的地方。应用服务器提供的错误信息对于我们来说是非常有
6、限的。如果为每一个类都编写单元测试并让每一个方法测试通过，又会是怎么样的开发情景 呢？编写测试代码-编写业务代码-运行测试方法-修改代码让测试通过-所有的类都通 过测试-打包-发布到服务器-进行功能测试-发现 bug-修改测试代码-修改业务代码- 测试通过-再打包如此循环。从上面的过程显而易见，我们需要花费更多的编码时间。因为需要为每一个业务类编 写测试代码。但是它并不会导致我们总体需要花费更多的时间。我们只是可以非常轻松的 在 ide 环境中运行测试方法。在代码尚未打包发布之前我们就已经确保了业务代码的正确 性。当我们把所有通过测试的代码集成到应用服务器后，出现错误的机率要少得多。当集 成测
7、试后发现 bug 时,我们也总是先修改测试类。保证在集成之前所有的类都经过测试通过。 这样功能测试的时间就成数量级的减少,所以总的花费时间要比没有单元测试要少得多。另外，如果没有单元测试，会经常出现一些低级的错误，如拼写错误，空指针异常等。 就因为一个小小的拼写错误而需要重新打包，发布一次。如果有单元测试，就可以避免这 些低级的错误。如果没有单元测试，把代码集成到应用服务器后再发现错误时，我们往往更多的是凭 借自己的经验来判断问题出在哪里。对于没有经验的程序员来说只能是撞运气了。这就像 是瞎子走路一样，两眼一把黑。如果每个类都有单元测试，就无需要这么痛苦了。2.业务逻辑简单，不值得编写单元测试
8、在项目开发中，我们需要经常通过重构来优化代码及改进我们的设计,当我们对代码进 行重构之后，怎么能够保证代码仍然是正确的？那就是运行所有被修改的代码的测试。如 果测试通过，则说明我们的重构是正确。我们不能回避代码的维护问题。代码维护包括修正 bug 和增加功能。维护工作可能会 距离代码编写完成有很长一段时间。当需要修改一个 bug 而修改了代码，或增加一个新的 功能而修改了代码时，又怎么能够保证修改后的代码仍然是正确的和没有隐患的呢？只要 修改测试用例进行测试就能知道修改的代码是否符合要求了。3.不知道怎么编写单元测试如果你相信单元测试的价值，那么去学习如何编写单元测试最终会让你获益的。 所以我
9、们应该掌握一些编写单元测试的基本原则:1)应该为什么编写测试： 虽然我们说为所有的代类都编写单元测试，但是测试 JavaBean 的 setter 或 getter 方法 无异于是自寻烦恼。编写这样的测试完全是浪费时间。而且还增加了维护的困难。2) 学会使用断言： 断言就是让我们为方法设置一个期望值。当方法执行结果与期望值不一致时，测试组 件就会报告测试不通过。我见过一些项目的单元测试不是使用断言，而是自己编写一个打 印(println)工具类，可以详细的在控制台中打印出类的详细成员信息，及集合的详细信息。 在单元测试中使用这个打印工具类来打印输出结果。这看起来好像非常不错。但是不应该 使用这
10、种方式来编写单元测试 使用打印工具类，需要程序员自已从控制台去观察程序的执行结果。当输出信息非常 多时，控制台信息是无法向上翻屏的。所以不能够给我们提供更多的信息。所以这种方法 也不能用于自动化测试。 使用打印工具类，造成了一种假像，测试报告我们的测试总是成功的！如果使用断言， 当方法的执行结果与我们设置的期望值不一致时，则会详细的报告测试失败的情况。 使用打印工具来代替断言，造成测试的不充分，只会写出一个低测试覆盖率的测试。 我们需要一个充分的测试。3) 最大化测试覆盖率： 我们除了测试一个正确的路径外，我们还需要测试方法的每一个分支逻辑。需要编写 尽可能多的测试程序逻辑的测试。写一个充分的
11、测试。4) 避免重复的测试代码： 测试类也是非常重要的，与应用代码一样。测试类包含的重复代码越多，测试类自身 出现的错误也会越多。而我们需要做的编码工作也就越多。5) 不要依赖于测试方法的执行顺序： 使用 Junit 来进行单元测试，它不能保证测试方法按照我们的意图的顺序来执行。当一 个测试类有多个测试方法时，我们不能让一个测试方法必须在某一个测试之后执行才能成 功。Junit 不能为我们做这样的保证，我们不能依赖于测试方法的执行顺序。6) 针对接口测试： 我们有“针对接口编程”的 oo 设计原则。同样对于测试，我们也需要针对接口测试。也 就是说在编写单元测试时，测试对象总是使用接口，而不是使
12、用具体类。4.项目没有要求，所以不编写的确在很多项目中，团队并没有要求程序员为每一个类编写单元测试。反而会要求 我们编写很多复杂的文档。作为程序员我们需要明白：程序员是编写单元测试的最大受益 者。这不是项目经理的事，也不是 QA 的事，而是程序员自身的事。因为单元测试是程序 代码的一部份。单元测试是最好的，最有价值的文档，它应该与代码一起交付给客户。单元测试代码不是官僚，死板的文档。它是生动的，是程序员最有用的文档。单元 测试能够提高程序员对程序的信心，能够使用养成良好的设计原则：“针对接口编程，而不 是具体类”。因为要进行单元测试，所以我们需要让类独立于其依赖对象(使用 Mock 或 stu
13、b)进 行测试。这就迫使我们养成了良好的编程习惯。单元测试是改进我们设计的保证。做为一个优秀的程序员，是会经常优化代码和设 计，所以经常的进行重构。一个优秀的程序员绝对不能容忍异味代码。而单元测试就是我 们进行重构的信心保证。单元测试是一个日常开发活动，它贯穿于项目的整个生命周期。做一个负责任的程 序员总是为自己的代码的质量负责的。是否经常改进你的设计，是否让别人很轻松的使用 和修改你的代码。为所有类编写单元测试应该是一个程序员应具有的素质。项目有没有要求，不应当成 为不编写单元测试的理由。Java 如何进行单元测试如何进行单元测试Android ：Android 1.5 已经内置 JUnit，可以直接编写 test 程序来进行单元测试J2ME需要使用 ant+JUnit。Junit 教程：192.168.1.201分享培训javaJUnit.in.Action 中文版.pdf
