From: John W. L. <Joh...@sa...> - 2010-04-29 20:33:45
|
I don't see where you are deleting classes.dir. Just make sure you do not instrument classes that are already instrumented. Correct me if I am wrong, but your tests run in a different process than your application. Your application runs in weblogic, right? If so, then adding the code from the FAQ to the teardown methods will not work. You have to execute the code in weblogic. There is a coberturaFlush.war file that can be loaded into weblogic that can assist with this. Then, you can just call a URL to do the flush. I can find the URL for you if you want to do it this way. Next, I see that gems.ejb.file is created with the instrumented classes in it, but I do not see anywhere gems.ejb.file is being used. I see a gems.ejb.file.name in the package-gems-ear-for-apps-server, but that is not gems.ejb.file. So, I'm not even certain that weblogic is loading the instrumented classes. If this is the case, then the only thing you would see in the ${basedir}/cobertura.ser file is the coverage of classes loaded by the test client. I'm assuming your tests do not exercise any of the instrumented classes directly. The tests exercise the application by communication with weblogic. Therefore, the coverage would be zero. Next, I would not put the cobertura.jar into the gems.ear.file. You will want weblogic to load that in its root classloader. In Tomcat, that means putting the cobertura.jar in Tomcat's lib directory. I don't know the corresponding directory in weblogic. Some old code of mine makes me think that we used to put the cobertura.ser file under weblogic's installation dir under user_projects/domains/MyDomain. John From: Khue Vu [mailto:kh...@gm...] Sent: Thursday, April 29, 2010 6:28 AM To: John W. Lewis Cc: cob...@li... Subject: Re: [Cobertura-devel] Using Cobertura with cactus test: Hi John, I search over my harddisk a few time but the file nowhere to be found. There is only the cobertura.ser file generated when I first instrumented the classes. If I generate report from this one, there will be 0% coverage. It definitely need to save to the ser file somewhere right? as I get it from WL log output: Flushing results... Flushing results done Cobertura: Loaded information on 23 classes. Cobertura: Saved information on 23 classes. Is there away I can force cobertura to print out where it save information to ? Thanks for your help Regards Khue. On Thu, Apr 29, 2010 at 6:08 PM, John W. Lewis <Joh...@sa...<mailto:Joh...@sa...>> wrote: The cobertura.ser that is being updated by weblogic is bound to be on your hard drive somewhere. I would search the entire hard drive if you have to, but first I would look under the entire weblogic installation. Let me know how it goes. John From: Khue Vu [mailto:kh...@gm...<mailto:kh...@gm...>] Sent: Thursday, April 29, 2010 1:59 AM To: cob...@li...<mailto:cob...@li...> Subject: [Cobertura-devel] Using Cobertura with cactus test: Hi all I have problem when using cobertura with cactus. I run the test and flush the result fine. Here is the output log of Weblogic Server: Flushing results... Flushing results done Cobertura: Loaded information on 23 classes. Cobertura: Saved information on 23 classes. Flushing results... Flushing results done Cobertura: Loaded information on 23 classes. Cobertura: Saved information on 23 classes. Query is null Total size is 88 First result is 0 maxRows is 25 result size is 25 Flushing results... Flushing results done Cobertura: Loaded information on 23 classes. Cobertura: Saved information on 23 classes. Query is null Total size is 10 First result is 0 maxRows is 25 result size is 10 Flushing results... Flushing results done Cobertura: Loaded information on 23 classes. Cobertura: Saved information on 23 classes. So the result is flushed but when the coverage report is generated, I always get 0% coverage. And according to the Cobertura FAQ, there will be cobertura.ser file in the working directory of server(WLHOME/server/bin) but I can't find it there. ( I add the code from FAQ to tearDown() methods of test cases so that server need not to shutdown to flush the result: try { String className = "net.sourceforge.cobertura.coveragedata.ProjectData"; String methodName = "saveGlobalProjectData"; Class saveClass = Class.forName(className); java.lang.reflect.Method saveMethod = saveClass.getDeclaredMethod(methodName, new Class[0]); saveMethod.invoke(null,new Object[0]); } catch (Throwable t) { } ) Any suggestion? What did I do wrong? Here is part of my build.xml file: <target name="intrument-classes-for-coverage-testing" depends="move-toplink-files-to-deployment-folder, compile-gems" > <echo message="--instrumenting classes--" /> <!-- delete the cobertura file which contain the info of instrumented classes --> <delete file="${basedir}/cobertura.ser" /> <cobertura-instrument > <fileset dir="${classes.dir}"> <include name="**" /> </fileset> </cobertura-instrument> <!-- generated cobertura.ser is at base by default --> </target> ... <target name="package-gems-ejb" depends="intrument-classes-for-coverage-testing" description="compiles and packages the gems ejb jar file"> <echo message="--- Packaging gems ejb ---"></echo> <delete file="${gems.ejb.file}"/> <jar destfile="${gems.ejb.file}"> <fileset dir="${classes.dir}"> <include name="**"/> </fileset> <fileset dir="${gems.base.dir}"> <include name="toplink\DAPS\descriptors\*.xml"/> </fileset> <metainf dir="${gems.source.dir}/META-INF"> <include name="*.xml"/> </metainf> <manifest> <attribute name="Class-Path" value="${search.jar.file.name<http://search.jar.file.name>} commons-logging.jar cobertura.jar" /> </manifest> </jar> </target> <target name="package-gems-ear-for-apps-server" description="compiles and packages the ear file, " depends="package-gems-ejb"> <echo message="${gems.ear.file}" /> <delete file="${gems.ear.file}"/> <ear destfile="${gems.ear.file}" appxml="${gems.config.dir}/META-INF/application.xml"> <fileset dir="${deployment.dir}"> <include name="${gems.ejb.file.name<http://gems.ejb.file.name>}"/> <include name="${search.jar.file.name<http://search.jar.file.name>}"/> </fileset> <fileset dir="${buildlib.dir}"> <include name="commons-logging.jar" /> </fileset> <fileset dir="${cobertura.dir}" > <include name="cobertura.jar" /> </fileset> <metainf dir="${gems.config.dir}/META-INF"> <include name="weblogic-application.xml"/> </metainf> </ear> </target> <target name="cactify-gems-ear-file" depends="package-war-file-for-gems-test-cases"> <echo message="--Cactifying ear file--" /> <cactifyear srcfile="${gems.ear.file}" destfile="${gems.cactified.ear.file}"> <cactuswar srcfile="${gems.cactus.test.war.file}" context="DapsWS-DataModel-context-root" /> </cactifyear> </target> <!-- deploy to gems-ear to application server --> <target name="deploy-cactified-gems-ear-to-app-server" depends="cactify-gems-ear-file"> <echo message="--Deploying to app server--" /> <wldeploy action="deploy" verbose="true" debug="true" name="GEMS" source="${gems.cactified.ear.file}" user="weblogic" password="weblogic1" adminurl="t3://localhost:7101" targets="DefaultServer" /> </target> <target name="move-cactus.properties" depends="deploy-cactified-gems-ear-to-app-server"> <echo message="Moving" /> <copy todir="${deployment.dir}/classes" > <fileset dir="${gems.base.dir}/classes"> <include name="cactus.properties" /> </fileset> </copy> </target> <target name="run-with-junit" depends="move-cactus.properties"> <junit printsummary="false" fork="yes" forkmode="once" > <sysproperty key="net.sourceforge.cobertura.datafile" file="${basedir}/cobertura.ser" /> <formatter type="brief" usefile="false" /> <formatter type="xml" /> <classpath location="${classes.dir}" /> <classpath location="${test.classes.dir}" /> <classpath refid="cactus.classpath" /> <classpath refid="buildlib" /> <classpath refid="testlib" /> <classpath refid="cobertura.classpath" /> <test name="packagename.TestClass" todir="${test.report.dir}"> </test> </junit> </target> <target name="generate-coverage-report"> <cobertura-report format="html" destdir="${coverage.report.dir}" srcdir="${gems.source.dir}" datafile="${basedir}/cobertura.ser" /> </target> Thank you very much. |