周末札记

  这周末基本上是在上海师大里面度过的 -- 由于需要用笔记本看电子书，所以很荣幸的成为了自习教室里插线板的专业供应户...好吧，我承认在使用小黑的过程中也休闲了一次--玩了一把扫雷^_^
  Oreilly的ANT书讲到JUnit测试的ANT处理了，虽然知道JUnit的使用，但是对于测试（Test）这一在软件工程领域越来越重要的技术， 自己了解的并不多；对于测试驱动开发（TDD）这一敏捷编程方式也只有耳闻；所以就重新翻开了Manning出版社的JUnit in Action。
------------------
  最重要的基本类：TestCase TestSuite
  测试的评价：测试覆盖率、测试报告生成
  测试驱动开发：Test-Driven Development 流程
  测试与ANT的集成：可以自动化进行软件部署前的test工作
  测试与Maven的集成：可以避免手动书写大量的测试ANT脚本
  测试与Eclipse的集成：这个可能是自己用的最频繁的吧
  几大测试的种类：接触代码最多的是“逻辑单元测试”（unit test），说是“逻辑”，指的是这种测试注重Java方法的输入输出是否符合预期的逻辑；比较麻烦的是"Integration Test"，工作流产品中各个组件之间的关系和作用是否正确等等...“功能测试”注重软件产品最终是否能够给出需要的功能（平时分配给自己的任务，做完 了看看有没有效果出来，估计这就算最基本和初级的功能测试了吧）。"Stress/Load Test"则是测试代码在不同的运行环境下的响应情况，从而可以找到影响运行效率的代码块。"Acceptance Test"一般由用户或公司里的QA（质量控制）组成员来施行，以做最后的产品通过检验。
  逻辑单元测试(unit test)在一般情况下不是很难写，其一个潜在的好处在于可以帮助程序员提高代码质量--任何一个Java方法，如果发现很难写出对它的单元测试代码，那么该程序基本上需要被重构。
  对于Integration Test，上述潜在好处依然存在；这种测试的麻烦在于：搭建J2EE和数据库等真实服务环境，模拟各种正常的/错误的信号，是一件很头痛的事情 -- 而且还不方便用cron(Linux操作系统下面)或者计划任务(Windows操作系统下面)来做定期自动测试。
  解决Integration Test的诀窍，在于“弄虚作假”:-P
  “假货”之一：stub。就是创建一个继承类（继承方法中传入的那个类，如HttpRequest），但是将该类中与测试相关的功能简单化，这样就可以绕开与被测试代码无关的东西。
  “假货”之二：mock。一般是实现一个接口（方法中传入的那个接口），但是却不做任何实质性的工作，这样也可以绕开原来令人感到麻烦的地方。
  stub与mock的区别：stub保留业务逻辑（简单的可以理解为保留很多功能），mock则基本上是个空架子；与此相应的，stub一般是继承（extend），而mock则一般是实现接口（implement）。
  对于需要真实环境来做测试背景的情况来说，一般采取in-container Test方案。Jetty是一个模拟J2EE服务器的jar包，非常有用。而这种in-container Test方案用到apache的Cactus框架，可以大大的增加测试效率。
---------------------------------
  好吧，我承认这是一篇技术流水帐，目的只是为了让自己总结一下学到的东西，以后可以来回顾查阅一下^_^ 当然如果有对测试感兴趣的筒子看到这篇文章觉得还有点用，那真的是三生有幸了；如果看到什么地方写的不对，也希望可以不吝指正。
  p.s. 我不是搞测试的，所以并不专业哈:-)
  p.p.s 鼻涕、喷嚏，明天还得去搞IT，好像被某人给遥控感染掉了^_^～