On Mar 29, 2006, at 10:50 AM, Martin Zaun wrote:
Michelle, Craig, Michelle Caisse wrote:I have JDO-293, which is dependent on JDO-273 finishing touches. There's also JDO-64 that is still open. And JDO-349.-- Michelle
I'm going to address all of the issues currently annotated as "fix for 2.0 final" today. [As soon as JIRA is alive again]
I currently cannot lookup JDO-293 (apache server seems to be down), so, I'm not sure about your dependency, but I don't anticipate code changes for JDO-273 (and will set it to resolved after my AI below). Michelle Caisse wrote: >> It would be great if you could add anything that you know is missing, as > a range of assertion numbers or a set of ranges. Then I could check it> against the spreadsheet and make sure we have all tested assertions > marked "yes". What I'd recommend is that - the StateTransition tests only refer to A5.9.1..190, which denotes the global state transition table in the spec and that - we mark all other state-transition related assertions in the lifecycle tab of the spreadsheets as duplicates of A5.9.1..190, as is done for a few (but not all).
This sounds like a reasonable approach. I don't know if there is value in adding duplicate assertions to the test cases. I think these can be handled by referring the duplicates to the state transition section of the assertion spreadsheet.
I'm currently going over the lifecycle spreadsheet, checking the transition-related assertions for coverage by A5.9.1..190 and the newly implemented cases, and preparing a few comments (which I'll send to you soon). Now, for the unlikely event that I find any transition assertions not covered by the global state transition matrix (A5.9.1..190), Craig would propably rather want to complete the matrix in the spec (errata) instead of me adding additional assertions to StateTransition*.java. But even if I did update StateTransition*.java, it only would be for a message string and a comment.
The structure of the StateTransition test class makes it difficult to identity the specific assertion causing the failure, but the enhanced messages on failure make it clear that there is a violation of the lifecycle table and the text indicates the exact scenario that is failing.
Craig
Martin
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
