TDD-J2EE Example

第三章基本知识

1）单元测试基本套路

  1. 从序列图中划分出类的基本框架，针对每个类的功能，从上到下编写单元测试

  2. 测试的组织：一个testSuite for 整个工程，多个testSuite for 每个包。

  3. 构造 ant script运行测试：编译和打包源代码；编译和打包测试代码；运行测试；输出到xml文件; junitreport将xml文件产生报告。

  4. 测试的包结构：和源代码结构类似，如/src/com/apress/tddbook/   /test/com/apress/tddbook.

 

2）依赖环境

  尽量减少依赖，方法有stub和mock object。

stub是依赖环境类的简化实现，缺点是随着版本的演变会变得复杂，常用在需要和依赖环境进行多次交互的场景；

mock object是通过框架规范依赖环境类的行为，优点是针对单一测试。

第四章：测试驱动开发 for Servlet和JSP

  1. Jsp和Servlet开发的难处：需要容器测试，解决方法：使用模拟工具，如MockRunner或ServletUnit；使用容器内测试，如Cacus, jetty(可嵌入到java代码的servlet容器)

  2. 使用TDD开发Servlet: 使用httpUnit中的servletUnit进行开发，通过设置parameter和attribute获得前台提交的数据，在struts2中没用，只需要对action对象设置相应值即可。

  3. 使用TDD开发JSP:测试哪些数据要传递给view. 思路是解析传递过来的response，得到其dom，table,image结构，判断数据是否存在。如果在struts2中也没用，可调用action的特定函数，并对相应的property进行判断。

第五章：开发用户接口

  1. 使用RMI或Spring实现客户端的远程调用，实现时首先使用测试驱动开发的思路建立远程service的stub bean；创建gui 的shell，只包含组件，没有任何函数和属性；使用jfcUnitTest测试驱动开发界面操作。

  2. gui测试的优势：1）对于复杂系统的界面，使用TTD可以更好的把握需求; 2)并为回归测试设定良好的基线；

  3. gui测试的局限；1）多为黑盒测试；2）效果不能立刻显现，多用于回归测试；

第六章：集成阶段

  1. 在基于database mock基础上的其余部件使用测试驱动开发完毕后，对database 的接口进行真实的实现。  DBUnit is a JUnit extension 用于数据库测试，保证测试前数据库为已知状态，测试运行前，dbunit使用xml中数据去初始化数据库对应表

  2. dao类开发步骤：创建test，创建dbunitxml文件  创建dao类

  3. 程序集成时tdd的角色，完成集成

       0）先进行各部分的测试；

       1）去除servlet或jsp的mock object，并使用dbunit替代；

       2）集成servlet到应用服务器需要使用Cactus创建容器内测试。

       3) 自动化build-》deploy->test, 使用httpUnit进行基于jsp的end-end的测试 

       4)继续写测试，增强健壮性和覆盖率

  4. 将mock object 和dbunit作为不同的分支，并使用properties文件中的变量选择不同的运行分支。

第七章：改进过程

  1. 组织和运行；

a)         test和src放在src  test 并行的目录下；

b)        按目录组织testSuite；

c)         ant自动运行

  2. 将测试数据从测试分离：测试大致有三部分:输入数据，执行函数，验证结果。可使用jtestcase来分离logic和测试数据

  3. 创建test的基类，将配置信息（首页地址，连接数据库信息等）和通用的test methods放入

  4. making the tests configurable: 创建不同环境下的properties 文件，则使用ant更容易运行

  5. 测试覆盖策略：

       分支条件  边界值

  6. 使用测试调试代码：

1)      先在测试中构造bug出现的条件，找到bug的来源;

2)      测试中编写一系列的校验；修正bug；

3)      运行校验测试通过。

  7. 使用测试改进性能和扩展性：使用一个性能度量工具来分析程序的哪部分执行时间最长，可以写JUnitPerf测试用例，为这部分代码指定可接受的性能和效率参数。如果不对代码做任何改动的情况下直接进行测试将不会通过，接着对代码做一些小的调整。每次调整后都重新编译和运行JUnitPerf测试，直到测试通过

  8. 测试的管理：当需求变化时，重构代码和测试代码再增加功能。如果比较困难，请分析测试环境确定原因

  9. 逻辑简单不写测试是不行的，因为逻辑到后面会复杂。

第八章：向TDD改变

1. 学习测试框架和测试流程，并开始实战；

2. 开始尝试编写测试为MVC的不同部分；

3. 熟练后开始驱动开发，要坚持；

4. 使用新的测试框架和重构process

参考资料：

1.       www.testdriven.com 关于tdd的web站点