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.
2007/9/12, Stepan Mishura <[EMAIL PROTECTED]>:
> On 9/11/07, Sean Qiu wrote:
> > Yep, it should be ok in addition to the emma.jar.
> > By this mean, there is no need to modify original adaptors.
> > So we can just maintain a new adaptor to maintain the instrumented jre
> for
> > test.
> >
>
> Yep, no changes to the existing adaptors. So emma adaptor should just
> instrument jre's jars (+ add emma.jar to jre) and collect coverage
> reports from suites.
>
> Thanks,
> Stepan.
>
> > 2007/9/11, Stepan Mishura
> > >
> > > On 9/10/07, Sean Qiu <[EMAIL PROTECTED]> wrote:
> > > > Hi, guys
> > > >
> > > > Shall we integrate the emma into our BTI 2.0 to get the test
> coverage
> > > > report?
> > > > AFAIK, Robert has spent a number of time on using our unit test to
> emma
> > > > coverage report.
> > > > Maybe we can generate the coverage from the BTI test besides our
> unit
> > > test.
> > > >
> > > > IMHO, we can maintain a individual target as the "run-cc" target in
> > > > script/main.xml, like "run-coverage" or something else.
> > > > It will set up its requisite like an instrumented jre to run the
> test.
> > > > Before running the test, we need to add <jvmarg
> > > > value="-Xbootclasspath/p:${instrumented-classlib}"> for each
> adaptor's
> > > > tested jvm task.
> > > >
> > >
> > > Is is possible just to replace jars in lib/boot by instrumented jars?
> > >
> > > Thanks,
> > > Stepan.
> > >
> > > > Finally, the "run-coverage" command call each adaptor as normal
> except
> > > > assigning the ${instrumented-classlib} to the instrumented classlib
> > > jars.
> > > > The generated report can be placed to build/coverage-report or some
> more
> > > > proper places.
> > > >
> > > > I think this approach can extend the BTI 2.0 without too many
> > > modifications.
> > > > Are there any comments about this? Or any other approach? Any
> > > suggestion is
> > > > welcomed.
> > > >
> > > > --
> > > > Sean Qiu
> > > > China Software Development Lab, IBM
> > >
> >
> >
> >
> > --
> > Sean Qiu
> > China Software Development Lab, IBM
>
--
Sean Qiu
China Software Development Lab, IBM
