Hi Carsten,
one of the main features of JaCoCo is its low overhead and scalability
für *large* projects. To be honest I'm not willing to sacrify this for
this feature. Before we would need some serious testing with large scale
JaCoCo use cases. There are other tools like cubertura which follow
Marc, do you have a comment on this? Especially the "PS" is important to me
right now.
On Tue, Jan 6, 2015 at 3:04 PM, Carsten Otto wrote:
>
> Hi,
>
> first of all, sorry for the late reply. Holidays got in the way, and I
> also finally handed in my PhD thesis.
>
> To your question:
> The code c
Hi,
first of all, sorry for the late reply. Holidays got in the way, and I also
finally handed in my PhD thesis.
To your question:
The code change I proposed includes a probe in front of each INVOKE opcode,
which basically is the only change. This way one can see if the code
leading to the INVOKE
Hi Carsten,
I also experimented with this approach. Sadly, this approach is
worse, as you'd need a probe for every single opcode which might
throw an exception, in addition to said handler(s).
Why, you can do the same approximation as for invoke* opcodes: Just
declare handlers for method invo
Marc?
On Thu, Nov 20, 2014 at 11:00 PM, Carsten Otto
wrote:
> I'm looking forward to some kind of reply, if you find the time.
>
> On Tue, Nov 11, 2014 at 12:00 PM, Carsten Otto
> wrote:
>
>> Hi Marc,
>>
>> after some troubles understanding your mail, I think I now get what your
>> main questio
I'm looking forward to some kind of reply, if you find the time.
On Tue, Nov 11, 2014 at 12:00 PM, Carsten Otto
wrote:
> Hi Marc,
>
> after some troubles understanding your mail, I think I now get what your
> main question seems to be.
>
> You are correct in that whatever JaCoCo might return as
Hi Marc,
after some troubles understanding your mail, I think I now get what your
main question seems to be.
You are correct in that whatever JaCoCo might return as a result, the
analyzed code still is the same. It is exactly as good or bad as it was
before running the analysis. Whatever change y
Hi Carsten,
thanks for this detailed analysis! The increase in probes is quite
substantial. Interesting to see that the factor is that different for
the different products.
What does the increased coverage mean at the end? The tests itself are
not improved by using a different JaCoCo version
Hi,
I had troubles with several Apache Commons projects, but I managed to
compile some interesting results nevertheless.
In short:
- Adding probes for every INVOKE opcode results in about 2.4x as many
probes.
- The runtime ranges from 100% to 146% of the current JaCoCo release.
- The number of in
Hi,
we discussed this limitation many times before. Currently JaCoCo is
designed to add the smallest possible overhead to the application under
test as JaCoCo is mainly used for large scale projects.
I like the idea of adding additional probes before every INVOKE*
instruction as this is the
Dear all,
JaCoCo does not detect that certain instructions are run (covered) if these
lead to an implicit exception. In the following example, if c() throws an
exception, the result indicate no coverage for b().
public void foo() {
a();
try {
b();
c();
} catch (Throwable t) {}
}
In
11 matches
Mail list logo
