This is the mail archive of the mailing list for the Mauve project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Mauve Code Coverage


> I take your point that it >>could<< be more convenient for testcase
> developers to run the coverage tests themselves.  But that assumes that
> the "barrier to entry" for using the tool isn't too high.
> 1)  I assume that Koalog will want to limit the their offer of free
> licenses to "testcase developers".  


> Have you considered how many you will
> provide, 

As many as developers.

> and your criteria for deciding who to give them to?  

No criteria.

> Will there be
> much paperwork?


> 2)  How easy will it be to use the coverage tool?  In particular, is it
> much work to install the tool?  Is it much work to set up the coverage
> tool for a particular project?  [Could the setup files be CVS'd?]

Install is very simple, it takes a couple of seconds.
It is also very easy to set up the tool for a given project.
For more information about these points, look at the user guide.

> 3)  Does the tool cope with calls (and callbacks) from Java and native
> code?  A lot of this happens in a typical Classpath-based VM.

No. To be more precise, KCC will only compute the code coverage for the Java 
byte code.

> Am I missing something here?  Can a Classpath cleanroom developer really do
> a coverage analysis of running Mauve testcases against a Sun JDK?  Doesn't
> the developer need to use Sun source code to do this?

You can use any JDK as long as it is JPDA compliant (Sun and IBM JDKs are).
You don't need any source (since KCC does not instrument the code), you just 
need the jar files.
You will need the source to see the result line per line (in KCC GUI only).

Does it make sense?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]