Makes sense.
Thanks
/Sudha
-Original Message-
From: Santhosh Edukulla
Sent: Wednesday, December 11, 2013 4:33 AM
To: Sudha Ponnaganti; dev@cloudstack.apache.org
Subject: RE: Tiered Quality
1. The below snapshot only depicts numbers only for KVM run.( A sample run ).
2. We will
chance to
provide better inputs.
Thanks!
Santhosh
From: Sudha Ponnaganti
Sent: Wednesday, December 11, 2013 7:26 AM
To: dev@cloudstack.apache.org
Cc: Santhosh Edukulla
Subject: RE: Tiered Quality
Thanks Santhosh for the coverage numbers. Does this include only
.
Thanks
/sudha
-Original Message-
From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com]
Sent: Wednesday, December 11, 2013 2:52 AM
To: dev@cloudstack.apache.org
Subject: RE: Tiered Quality
Coverage information for both unit and integration tests for a sample
regression run.
http
once we can add report plugin to it.
Regards,
Santhosh
From: Daan Hoogland [daan.hoogl...@gmail.com]
Sent: Sunday, November 03, 2013 7:07 AM
To: dev
Subject: Re: Tiered Quality
keep us posted before breakthrough as well, please. I'm very interested.
iday, November 01, 2013 10:48 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Tiered Quality
>
> I have heard about commercial tools that do more advanced coverage
> tracking. But if you think in open source, not sure Sonar really has an
> alternative. It is pretty cool anywa
> >>
>> >>
>> http://docs.codehaus.org/display/SONAR/Code+Coverage+by+Integration+Tests+for+Java+Project
>> >>
>> >> 3. Many links suggests it has good decision coverage facility compared
>> to other coverage tools.
>> >>
>&g
.
From: Laszlo Hornyak [laszlo.horn...@gmail.com]
Sent: Friday, November 01, 2013 10:48 AM
To: dev@cloudstack.apache.org
Subject: Re: Tiered Quality
I have heard about commercial tools that do more advanced coverage
tracking. But if you think in open source, not
facility compared
> to other coverage tools.
> >>
> >>
> http://onlysoftware.wordpress.com/2012/12/19/code-coverage-tools-jacoco-cobertura-emma-comparison-in-sonar/
> >>
> >> Regards,
> >> Santhosh
> >>
other coverage tools.
>>
>> http://onlysoftware.wordpress.com/2012/12/19/code-coverage-tools-jacoco-cobertura-emma-comparison-in-sonar/
>>
>> Regards,
>> Santhosh
>> ____
>> From: Laszlo Hornyak [laszlo.horn...@gmail
> http://onlysoftware.wordpress.com/2012/12/19/code-coverage-tools-jacoco-cobertura-emma-comparison-in-sonar/
>
> Regards,
> Santhosh
>
> From: Laszlo Hornyak [laszlo.horn...@gmail.com]
> Sent: Monday, October 28, 2013 1:43 PM
> To
From: Laszlo Hornyak [laszlo.horn...@gmail.com]
Sent: Monday, October 28, 2013 1:43 PM
To: dev@cloudstack.apache.org
Subject: Re: Tiered Quality
Sonar already tracks the unit test coverage. It is also able to track the
integration test coverage, however this might be a
Sonar already tracks the unit test coverage. It is also able to track the
integration test coverage, however this might be a bit more sophisticated
in CS since not all hardware/software requirements are available in the
jenkins environment. However, this could be a problem in any environment.
On
We need a way to check coverage of (unit+integration) tests. How many
lines of code hit on a deployed system that corresponds to the
component donated/committed. We don't have that for existing tests so
it makes it hard to judge if a feature that comes with tests covers
enough of itself.
On Sun, O
Ok, makes sense, but that sounds like even more work :) Can you share the
plan on how will this work?
On Sun, Oct 27, 2013 at 7:54 PM, Darren Shepherd <
darren.s.sheph...@gmail.com> wrote:
> I think it can't be at a component level because components are too large.
> It needs to be at a feature
I think it can't be at a component level because components are too large. It
needs to be at a feature for implementation level. For example, live storage
migration for xen and live storage migration for kvm (don't know if that's a
real thing) would be two separate items.
Darren
> On Oct 2
I believe this will be very useful for users.
As far as I understand someone will have to qualify components. What will
be the method for qualification? I do not think simply the test coverage
would be right. But then if you want to go deeper, then you need a bigger
effort testing the components.
I don't know if a similar thing has been talked about before but I
thought I'd just throws this out there. The ultimate way to ensure
quality is that we have unit test and integration test coverage on all
functionality. That way somebody authors some code, commits to, for
example, 4.2, but then w
17 matches
Mail list logo
