[JSR358-31] Strengthen TCK quality requirements Created: 06/Jul/12  Updated: 12/Dec/12

Status: Open
Project: jsr358
Component/s: TCKs
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pcurran Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


The Process Document contains language intended to ensure TCK quality, but this is typically not enforced.

EC members have an obligation to review TCKs for quality before voting their Final Approval, but many do not.

Should we enforce or strengthen TCK quality requirements?

Comment by lightguard [ 20/Jul/12 ]

How would you propose we go about doing this? Seems like a tool would be useful. Perhaps something like what was done for CDI? http://docs.jboss.org/cdi/tck/reference/1.0.1-Final/html_single/#d0e791

Comment by ebresie [ 12/Dec/12 ]

Hope this is not out of scope...

To me Quality requirement implies a requirement is implemented as expected.

TCK seems more low level "Unit Test" level as opposed to higher level "Acceptance Test" level. Acceptance testing may have some overlap with unit test but they are still slightly different.

Maybe the Spec could better spell out the Acceptance criteria requirements.

Or maybe some form of TCK (Acceptance Test Plan) Spec with Acceptance requirements defined could help. Drawback is could potentially add extra "work" to the mix, but this could potentially allow "clean implementations" to implement there own TCK relative to the TCK Spec requirements.

Comment by ebresie [ 12/Dec/12 ]

I assume this is address by other non-implementer involvement, but there may still be some bias among participants.

Should an "independent" participant not involved in the group be considered to insure quality? Maybe a Quality EG?

Generated at Sat Feb 25 00:15:37 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.