You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by kelvin goodson <ke...@gmail.com> on 2007/10/05 13:12:26 UTC
[Java SDO CTS] enhancing the CTS
I've been thinking about the CTS a bit lately; trying to take stock of
what we've got, and how we measure up. The CTS went through a period
of healthy growth a while back, but I didn't manage to get a good feel
for how well we were covering the API combined with the range of
possible inputs to it. I ran the maven clover plugin to try to get
some idea of how well we cover the API, but the results show coverage
for the implementation classes, and it's not easy to get a good
picture for how good the coverage of SDO API interface from that data
(For example, there's much code in the Tuscany SDO implementation to
support generated code which of course doesn't get exercised by the
CTS). Does anyone know of good techniques for getting pure API
coverage data?
It would be good to get some structure into the CTS to make it more
evident in the test code what is covered, and what is not. I'm
thinking about perhaps restructuring and adding to the tests to
achieve this. I may end up just adding stub tests in the first place
in some places to highlight the fact that we are deficient in that
area.
Kelvin.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [Java SDO CTS] enhancing the CTS
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Hi Kelvin,
Getting the CTS structured in a way that better reflects exactly what APIs
are being tested sounds like a great idea to me. I also like the idea of
stub tests so that anybody, with a little time to spare, can easily
write/contribute a missing test.
Frank.
"kelvin goodson" <ke...@gmail.com> wrote on 10/05/2007 07:12:26
AM:
> I've been thinking about the CTS a bit lately; trying to take stock of
> what we've got, and how we measure up. The CTS went through a period
> of healthy growth a while back, but I didn't manage to get a good feel
> for how well we were covering the API combined with the range of
> possible inputs to it. I ran the maven clover plugin to try to get
> some idea of how well we cover the API, but the results show coverage
> for the implementation classes, and it's not easy to get a good
> picture for how good the coverage of SDO API interface from that data
> (For example, there's much code in the Tuscany SDO implementation to
> support generated code which of course doesn't get exercised by the
> CTS). Does anyone know of good techniques for getting pure API
> coverage data?
>
> It would be good to get some structure into the CTS to make it more
> evident in the test code what is covered, and what is not. I'm
> thinking about perhaps restructuring and adding to the tests to
> achieve this. I may end up just adding stub tests in the first place
> in some places to highlight the fact that we are deficient in that
> area.
>
> Kelvin.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [Java SDO CTS] enhancing the CTS
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Hi Kelvin,
Getting the CTS structured in a way that better reflects exactly what APIs
are being tested sounds like a great idea to me. I also like the idea of
stub tests so that anybody, with a little time to spare, can easily
write/contribute a missing test.
Frank.
"kelvin goodson" <ke...@gmail.com> wrote on 10/05/2007 07:12:26
AM:
> I've been thinking about the CTS a bit lately; trying to take stock of
> what we've got, and how we measure up. The CTS went through a period
> of healthy growth a while back, but I didn't manage to get a good feel
> for how well we were covering the API combined with the range of
> possible inputs to it. I ran the maven clover plugin to try to get
> some idea of how well we cover the API, but the results show coverage
> for the implementation classes, and it's not easy to get a good
> picture for how good the coverage of SDO API interface from that data
> (For example, there's much code in the Tuscany SDO implementation to
> support generated code which of course doesn't get exercised by the
> CTS). Does anyone know of good techniques for getting pure API
> coverage data?
>
> It would be good to get some structure into the CTS to make it more
> evident in the test code what is covered, and what is not. I'm
> thinking about perhaps restructuring and adding to the tests to
> achieve this. I may end up just adding stub tests in the first place
> in some places to highlight the fact that we are deficient in that
> area.
>
> Kelvin.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org