当敏捷遇上瀑布

作者：网络转载发布时间：[ 2013/7/15 13:45:39 ] 推荐标签：

　　自动化构建

　　第一个需求说能够在一台裸机上进行代码检出、构建。自动化构建，敏捷开发的重要部分，能够坚决这个需求。很多开发人员使用IDE来进行构建，这对快速构建是有益的，但是你还需要一个独立的自动化构建脚本。ANT和Maven是基于java项目的两个自动化构建工具。Gant正在获得喜欢Groovy的开发人员的喜爱。不管怎么说，构建脚本不是项目私有的并且能够在任何平台上执行。

　　上例中的成功地自动化构建过程应该实现如下内容：

　　1. 在svn库中的应用代码首先应该包含所有的默认配置，否则要求开发人员来修改。同时还要包含一个构建脚本来自动化更新这些配置文件来代替手工修改。

　　2. 应该有一个主要的构建脚本来执行所有的这些应用组件的构建。

　　测试这个自动化安装脚本是一个好主意，让一个没有经验的开发人员来验证这些过程（安装、构建、部署）。这是一个迭代过程；如果这个开发人员遇到麻烦了，我们也应该考虑修订或者更新这个构建过程。

　　每个java项目也应该在项目根目录下面有一个readme.txt文件，来描述手工步骤（自动化构建脚本不能执行的）。举个例子，有些项目可能因为加密实现、JAAS配置需要在JRE安全设置上有所不同，这个readme文件也需要列出在服务器上构建和部署应用所需要的步骤。

　　构建安装：主构建脚本

　　假定项目包含很多EAR和WAR文件，手工的来执行每个组件的构建脚本是痛苦的，解决的办法是象上面说的那样，写一个主构建脚本。

　　注意如果每个独立的构建脚本都有一个默认的target也是很好的。主构建脚本简单的组织这些构建target即可。List 1 是一个主构建脚本例子

　　Listing 1。使用antde主构建脚本

　　这个ant主构建脚本调用call-ABCSecurityServices-build，不直接包含独立的构建target，这个主构建脚本仅仅委托任务并且组织多个任务。它也能决定任务被执行的顺序。然后所有的构件被复制到一个指定的位置。

　　假定这个构建经理需要为多个环境进行构建，在外部定义这些环境因素是一个很好的主意。很多时候，这些是配置文件，而不是EAR/WAR中的文件，他们能够被抽取放到应用服务器的类路径上。通过这种方式，EAR/WAR将与环境无关。在不同的环境里面仅仅需要改变这些配置属性即可进行构建。

　　这个主构建文件让构建经理的工作更加容易，同时实现了通过一个点击来进行构建的需求。

　　自动化测试

　　在很多瀑布模型项目中，开发人员开发完一个组件，然后手工执行一套单元测试。将来，如果修改了这个组件，开发人员需要再次手工执行这些单元测试。通常情况下，改变很小，仅需要测试影响的功能即可。在时间有约束并且假定这个改变不影响其他功能的情况下，这样做看起来合情合理，但是有时微小的改变也可能破坏关联的功能，这将只有在整个应用被测试的时候才能发现。

　　JUnit是自动化测试的一个选择。

　　测试方法

　　有很多的方法来执行自动化测试，对于不同的场景类型至少一把的好的测试工具。

　　DBUnit，是一个基于JUnit的数据库脚本测试工具。

　　EasyMock 是一个开源的工具，可以用来创建模拟对象或者模拟接口，这样你不需要依赖第三方代码。

　　DBUnit和EasyMock是内部组件测试的两个工具. 但是对于前面场景中开发人员遇到的那个问题，他的模块是第10步才执行又怎么样呢？这个开发人员如何才能保证他的模块可以和其他模块正常工作呢？

　　解决这个问题的关键是创建不同模块的端到端测试用例，这样模块被在一个组中被连接测试了。集成测试可以使用上面的任何一款工具来完成。在有些情况下，你需要一个技术框架来执行集成测试，一个选择是Spring testing module （如果整体上没有使用spring）。

　　Selenium 是用来测试web应用的一款的容易学习的测试工具。它是通过直接在浏览器中通过模拟用户操作来执行测试。

　　另一个可以增强你的自动化测试的工具是Cobertura 。它让你能够衡量代码覆盖率，或者多少你的代码、行被真正的测试了。

　　现在我们已经知道了所有上面这些工具，接下来在持续集成环境中使用他们。

本文内容不用于商业目的，如涉及知识产权问题，请权利人联系SPASVO小编(021-61079698-8054)，我们将立即处理，马上删除。