beta版(2010.1027)；后续继续完善

1. 单元测试/持续集成（实战交流） 刘珅，2010.10.27

2. Agenda 单元测试 (10’) 持续集成 (10’) 讨论 & 答疑 (10’)

3. 单元测试，我们走过的路 温故，可以知新

4. 什么时候写单元测试？ 写新代码时 发现bug时 产品发布后，在生产环境发现的bug，经常忽视了补充典型的单元测试 重构时 …… 单元测试的价值在后期才会体现出来，并且越往后价值越高； 但请记住前提：单元测试需要精心维护、不断积累和完善

5. 容易编写的情况 纯工具类的单元测试 不依赖于J2EE容器的单元测试

6. 不容易写的情况和应对思路 依赖数据库的单元测试 使用Mock 使用内存数据库：如H2、HSQL等 依赖Servlet API的单元测试 使用Mock 使用嵌入式Servlet容器: Jetty等 放弃；因为Action层次不应包含业务逻辑！ Manager/Service层的单元测试 使用Mock 建立和实际环境对应的单元测试环境

7. 实例：消除对物理数据库的依赖 内存数据库，随单元测试启动而启动 推荐用H2 DAO测试代码示例

8. 其他常见问题和困难 数据准备杂乱无序，导致单元测试代码晦涩 需要有个合适的数据准备框架（TODO） 如何有效考察单元测试的质量 覆盖率？ 人工检查？ 适合我们的：不是所有代码都要单元测试，重点是核心代码(80/20原则同样适用) 请在座各位补充其他困难 (3’) 有关意识形态、项目管理方面的问题，留到后面探讨；此处仅讨论具体操作层面的问题。

9. 持续集成 如果没有持续集成，单元测试的价值会大打折扣 原始的持续集成 Ant脚本 + OS的计划任务 有序的持续集成 CruiseControl：配置异常复杂，且只能从脚本配置 TW还有个易用些的版本，但是不免费 Bamboo：商业 Hudson：开源，免费 通过界面即可配置傻瓜化 由于其开放性，存在大量实用的plugin 支持用各种主流语言如Java、C、Flex开发的产品 ……

10. 用Hudson持续集成的效果(1) 已经用了一年，大大改进了持续集成过程；能不断完善，良性循环

11. 效果(2) – 及时邮件通知 Gmail查看Hudson的通知邮件

12. 效果(3) – 每次构建的代码库变化

13. 效果(4) – 各类报告和趋势 单元测试报告及趋势 编译器警告、代码TODO标记等趋势

14. 效果(5) – 在线Javadoc

15. 项目配置(1) - 基本设置

16. 项目配置(2) - 源码库设置 直接支持CVS、SVN 通过plugin可支持其他版本控制系统 支持无版本控制的情况（不推荐）

17. 项目配置(3) - 何时进行构建？ 定期构建 定期检查源码库，如有变化则构建 由其他项目触发

18. 项目配置(4) – 如何构建？

19. 项目配置(5) – 构建过程、构建后 设置最长构建时间 避免测试代码中的死循环无限执行下去 扫描编译警告等各类警告 发布各类报告、趋势图 邮件通知

20. 构建结果的状态（3类）及应用 Fail 任一环节出错 如某Ant脚本执行错误 Success 所有环节执行成功 Stable 所有环节执行成功，并且结果正确 Fail < Success (=Unstable) < Stable 比如，从单元测试报告分析出有1个没通过；则hudson会将此次构建标为Unstable而不是Stable

21. 小结：Hudson持续集成要点 触发条件 构建 调用ant脚本、命令行、maven goal等 因此可以做任何事：编译、单元测试、部署演示环境、生成安装程序等等 构建后的动作 发布各类报告/趋势图、Javadoc等 邮件/IM通知 可根据构建结果的状态，按需灵活配置

22. 总结 单元测试 时机 要领 质量检查 持续集成 要用的工具 JUnit、Ant(或Maven)、Hudson TODO

23. 可参考的资源 《JUnit in Action》 《单元测试之道》 …… Hudson Wiki (http://wiki.hudson-ci.org/) TRS内网相关专题、Dev4 Wiki ……

24. 讨论 新产品/项目如何把单元测试/持续集成加进来？ 对团队、人员的要求 项目进度紧张，人员不充足，如何持续集成？划算吗？ 老产品呢？

25. Q&A 坚持，就会胜利！ 欢迎探讨单元测试和持续集成实践，不断改进 http://t.sina.com.cn/isxylands