TCK thoughts

[Niclas Hedhman <ni...@hedhman.org>]

Gang,

I am sketching on the "TCK issue" and have identified some concerns that I 
would like to share and discuss.

* * Definition of Specification requirements * *
Specifications are evolvable, meaning at the point of a release, they have a 
version and what is in it is set in stone. There can not be any changes to 
the specification, and any 'undefined' areas must remain undefined until a 
revised version of the specification is released.

* * Decomposition of specification * *
Avalon should allow smaller specifications, one for each concern (SoC), each 
evolvable and versioned accordingly. Some concerns may have competing 
specifications, such as LifeCycle specifications.

* * Test Compatibility Kit (TCK) * *
The TCK is a composition of many parts. Along one axis, there is the 
separation of concern between ContainerCompliance and ComponentCompliance, 
and along the other axis is the separation of TestHarness, ComplianceSuite 
and SystemUnderTest. For each version of a speficiation, there must be a 
ComplianceSuite which is also versioned in the codebase itself.
The TestHarness brings in a SystemUnderTest and executes one or many 
ComplianceSuite(s), effectively able to test the system against one or many 
specifications.

TCK Harness for Components have the trouble to either do introspection (source 
or class), or have to deal with dependency resolutions of components, which 
may even render many components untestable.

TCK Harness for Containers have the problems of Inversion of Control, where it 
needs to invert (!) that. Perhaps there needs to be a Specification for 
Container Testability. The only alternative that I can see is that the 
Container provides the TCK Harness itself.


I think I stop here and see if anyone has some reflections.


Niclas

-- 
+---------//-------------------+
|   http://www.bali.ac         |
|  http://niclas.hedhman.org   |
+------//----------------------+

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: TCK thoughts

[Berin Loritsch <bl...@d-haven.org>]

Niclas Hedhman wrote:

> TCK Harness for Containers have the problems of Inversion of Control, where it 
> needs to invert (!) that. Perhaps there needs to be a Specification for 
> Container Testability. The only alternative that I can see is that the 
> Container provides the TCK Harness itself.
> 
> I think I stop here and see if anyone has some reflections.

One idea for testing the container is to have a Test Component, or set of test
components that excersize all the contracts from the component view point.

The TCK would provide the hook to create the container, and access the test
component.  If the container failed to create the component and satisfy its
requirements then the test failed.

There would probably have to be multiple tests of this type due to the different
contracts that need to be tested.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: TCK thoughts

[Jonathan Hawkes <jh...@adsnm.com>]

> * * Definition of Specification requirements * *
> Specifications are evolvable, meaning at the point of a release, they have
a
> version and what is in it is set in stone. There can not be any changes to
> the specification, and any 'undefined' areas must remain undefined until a
> revised version of the specification is released.

+1

> * * Decomposition of specification * *
> Avalon should allow smaller specifications, one for each concern (SoC),
each
> evolvable and versioned accordingly. Some concerns may have competing
> specifications, such as LifeCycle specifications.

+1


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org