harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Qiu" <sean.xx....@gmail.com>
Subject Re: [build test] Integrate Emma into BTI 2.0 to get code coverage report
Date Thu, 13 Sep 2007 09:56:45 GMT
This is a sample build.xml [1] for emma, there are three targets:
1) instrument:
    instrment the jre
2) run:
    run test within instumented jre
3) generate-reports
    collect the emma files to get a coverage report.

IMHO, a usual adaptor cannot fulfill this requirement.

[1] build.xml

 <target name="instrument" depends="init">
        <emma enabled="${emma.enabled}">
        <instr instrpathref="jar.location" destdir="${out.instr.dir}"
metadatafile="${coverage.dir}/metadata.emma" merge="true" />
  </emma>
  </target>

 <target name="run" depends="instrument" description="runs the examples">
  <java classname="junit.samples.AllTests" failonerror="true" fork="true">
            <classpath>
    <pathelement location="${out.instr.dir}" />
                <path refid="emma.lib" />
                <pathelement location="${test.dir}"/>
    <path refid="jar.location" />
   </classpath>
   <jvmarg value="-Demma.coverage.out.file=${coverage.dir}/sample.emma" />
  </java>
 </target>

  <target name="generate-reports" depends="run">
        <emma enabled="${emma.enabled}">
   <report sourcepath="${src.dir}">
    <fileset dir="${coverage.dir}">
     <include name="*.emma" />
    </fileset>
    <txt outfile="${coverage.dir}/coverage.txt" />
    <html outfile="${coverage.dir}/coverage.html" />
   </report>
  </emma>
  </target


2007/9/13, Stepan Mishura <stepan.mishura@gmail.com>:
>
> On 9/13/07, Sean Qiu wrote:
> > We all know the scenario for emma is :
> > 1) instument jre
> > 2) run test within the instumented jre and generate coverage file
> > 3) collect the coverage file and generate the coverage report
> >
> > For further study of emma, i have two concerns:
> > 1. We have to maintain this task outside the adaptor, since it need to
> run
> > the (3) step after test.
> >    This cannot be achieved elegantly by a single adaptor but add a new
> > target in main script like "run-cc"
> >     Agree? Commnets?
> >
> > 2. If we donot change the existing adaptor , the coverage file will be
> > placed in the dir where test is invoked.
> >    I think we should locate them in a fixed place at least, like
> > build/results/${test_suites}.
> >    A alternative solution is put them all in a stand along dir, like
> > build/emma
> >    For both of them, we need add a new line in existing adaptor to tell
> > emma where we want to place our coverage file.
> >    Is this modification acceptable?
> >
> > If nobody object, i will start to:
> > 1) Add the emma target in main script
> > 2) Try to put coverage file into a stand along dir
> >
> > Any suggestions are welcomed.
> >
>
> I think that no changes to the framework or existing adaptors are
> needed. Collection of coverage files and report generation for each
> suite can by done by emma publisher (like snapshot testing does).
>
> So I'd implement emma adaptor in the way similar to the snapshot
> testing, for example:
>
> 1) emma setup target - downloads and unpacks emma
> 2) emma run target - instruments jre
>
> 3) emma adaptor depends on jre to be instrumented (it may be snapshot,
> drlvm or hdk project)
> (i.e. emma.parameters.depends=(snapshot|drlvm|hdk))
>
> 4) all suites depend on emma project.
> ( <suite>.parameters.required.tested.runtime=${
> emma.parameters.shared.instrumented.jre})
>
> 5) create custom config.xml for CC with emma publisher for suites
> (<suite>..parameters.cc.config=${adaptors.dir}/emma/custom-config.xml)
>
> Thanks,
> Stepan.
>



-- 
Sean Qiu
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message