Hi,
Clover sounds good to me and I have tried it before.
+1 on the 75% test coverage.
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Tuesday, September 05, 2006 8:48 AM
Subject: Re: Test coverage, was: Process and content for next
release?
>
> On Sep 5, 2006, at 8:14 AM, Jeremy Boynes wrote:
>
>> On Aug 16, 2006, at 2:49 PM, Jim Marino wrote:
>>>> 2) SCA Core (spi, core, hostutil, test, plus apis once that
>>>> refactor is done)
>>>> Features I would like to see complete before we consider this
>>>> stable are:
>>>> Class loading changes
>>>> Integration of databinding framework
>>>> Support for async callbacks
>>>> Support for complex properties
>>>> Transitive dependency support
>>>>
>>> I'd also like to see much better test coverage than what we have.
>>> This is hard to quantify, but while code coverage does not
>>> guarantee good tests, it is an indicator. So, to have a metric,
>>> I'd like to see core (and other extensions) at 75% coverage when
>>> run through Clover. I picked Clover since it is a decent tool and
>>> license-friendly but if someone would like to suggest an
>>> alternative we could look at it as well.
>>
>> I think this goal is worth pursuing and would add that as a
>> criteria for the next release. Apache has a license for Clover so
>> we can all use it, Cobertura would be another alternative - any
>> preference here? Whatever we use, I don't think this should be
part
>> of the build right now (although that could change later) but that
>> the tool should be run periodically and the results published
>> somewhere (e.g. on our site).
>>
> I prefer Clover as it also has nice IDE integration. I also think
> test coverage should be run as part of an integration build and
> published since it is a general indication of areas that need work.
>
>> Now Jim here only mentioned the core but this would apply to other
>> extensions as well - I would be inclined to extend this
requirement
>> to any extension we consider "baseline" - any objections?
>>
> For extensions considered baseline, I think "respectable" code
> coverage (~75%) is definitely a worthy goal. For baseline
extensions,
> I would also add that we should also have a minimum bar in terms of
> what assembly features they support (e.g. state management, non-
> blocking, etc.).
>
>> --
>> Jeremy
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]