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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
