解惑

解己之惑,解人之惑

标签:Unit Test

.NET平台下的持续集成

比Java平台下的麻烦太多。光是一个Unit Test就折腾了很长时间,很多都推荐NUnit,但是用Visual Studio还得让大家都安装NUnit,也为了看看完全用微软的方案是否可行。
由于我们现在的持续集成的工具选的是TeamCity,所以主的build脚本只能基于NAnt,因为TeamCity虽然支持MSBuild或者VS,但是没有对应的Runner或者兼容的Agent,所以基本上等于不支持。
从NAnt里面调用VisualStudio的工程文件编译是没有问题,因为有nantcontrib,但是运行Unit Test就成问题了,google了很长时间也没有找到好的解决方案,有人自己写了dll去掉整个solution的unit test(微软的msunit),还有个Gallio项目,都不怎么好用,最后回到起点:使用命令行的方式,但是需要在TeamCity的机器上安装Visual Studio,还好我们是大企业版,随便装。
最后出来的build.xml:

<?xml version="1.0"?>
<project name="POC" default="build" basedir=".">
    <property name="nantcontribdll" value="c:/nantcontrib-0.85/bin/NAnt.Contrib.Tasks.dll"/>
    <property name="mstestcommand" value="C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\MSTest.exe"/>
    <property name="unittestdir" value="unittest"/>
    <property name="outputtype" value="debug"/>
   
    <target name="build" description="compiles the source code">
        <loadtasks assembly="${nantcontribdll}" />

        <msbuild project="MyProject\MyProject.csproj">
                <property name="teamcity_dotnet_use_msbuild_v35" value="true"/>
        </msbuild>
        <msbuild project="MyProjectTest\MyProjectTest.csproj">
                <property name="teamcity_dotnet_use_msbuild_v35" value="true"/>
        </msbuild>
    </target>
   
    <target name="unittest" description="Run unit test" depends="build">
        <delete dir="${unittestdir}" />
        <mkdir dir="${unittestdir}" />
       
        <exec program ="${mstestcommand}" commandline="/testcontainer:MyProjectTest\bin\${outputtype}\MyProjectTest.dll /resultsfile:${unittestdir}\MyProjectTest.trx" basedir="MyProjectTest"/>
    </target>
   
    <target name="clean" description="Clean output">
        <loadtasks assembly="${nantcontribdll}" />
        <delete dir="${unittestdir}" />
        <msbuild project="MyProject\MyProject.csproj" target="clean">
                <property name="teamcity_dotnet_use_msbuild_v35" value="true"/>
        </msbuild>
        <msbuild project="MyProjectTest\MyProjectTest.csproj" target="clean">
                <property name="teamcity_dotnet_use_msbuild_v35" value="true"/>
        </msbuild>
    </target>
</project>

对于NAnt需要特别说明的是:在TeamCity里面可以用NAnt0.85版本,但是本地调用的话必须用NAnt0.86beta1(当前最新版本),只有这个版本支持.net3.5,而TeamCity使用自己的方式支持.net3.5,就是我们看到的丑陋的teamcity_dotnet_use_msbuild_v35,不能定义一个全局的property了事,必须在每个msbuild任务里面定义这个property。

EJB单元测试框架

公司的产品要引入单元测试以及代码覆盖,让我做一个框架方便我们写单元测试代码,上网找了一下,找到一个不错的基础:MockEJB,大家可以先了解下相关的内容:
MockEJB项目简介信息
使用MockEJB简化EJB测试

我在这个基础上进行了扩充,框架具有如下的特性:

  • 读取EJB配制文件完成EJB的自动发布,框架会读取我们工程的ejb-jar.xml,jboss.xml,jbosscmp- jdbc.xml文件的配制信息并组合这些信息完成自动发布所需要的内容。
  • 共享的dummy数据,我们自己提供一个xml文件,里面存放一些dummy的数据,这些数据会在对应的Entity Bean被使用的时候自动插入数据库,完成数据的初始化工作(这样Session Bean中的SQL也可以取到一致的内容),在一个test方法结束的时候回滚,删除那些记录,消除Test Case之间的影响。
  • 自定义事务管理,每个test方法都处于同一个事务中,方法结束的时候事务回滚,消除Test Case之间的影响。
  • 支持部分find方法的实现,由于MockEJB对于Entity Bean只提供了对findByPrimaryKey的支持,甚至连findAll都不支持,框架在MockEJB提供的Aspect机制的基础上实现了 findAll等常用必备的find方法,并且对于自定义的find方法也提供部分支持,通过解析EJB配制文件中的SQL完成,但是可能性能不好,因为会遍历所有的记录并比较字段的值完成这个查找的过程。其它比较复杂的find方法(框架无法解析的SQL),需要自己实现对应的Aspect,框架会自动查找对应的Aspect。
  • Struts TestCase的基础上支持对Action的单元测试。

测试代码范例:
阅读全文

© 2024 解惑

本主题由Anders Noren提供向上 ↑