On May 24, 2011, at 11:58 PM, Mark Struberg wrote: > +1 how to start?
We should try to get a list of the @SpecAssertions from the various 'broken' tests. A little 'find|grep|sort|uniq' action, perhaps. Then see if we can't squeeze out some exception classes from them. Then start plumbing them into the code. It's getting late here so if someone wants to compile that list and post it, cool :) Otherwise I'll get to it tomorrow. > We have lots of internal tests, but I think the passivation example is really > overly strict in the spec (as you said on the CDI list). I'm not really > convinced by petes mail. Need to re-read his mail ot fully understand what he > meant. I had a reply, but it hit moderation as I wasn't subscribed. I though it was a tad negative so I just deleted it and sent a subscription request. Do you know if that list is open? -David > --- On Wed, 5/25/11, David Blevins <[email protected]> wrote: > >> From: David Blevins <[email protected]> >> Subject: Exception handling idea >> To: [email protected] >> Date: Wednesday, May 25, 2011, 6:43 AM >> Grinding through some of the "broken" >> packages of the CDI TCK and many of them are passing... some >> of them for the wrong reason. Any deployment issue >> counts as a win with those tests, so it's incredibly >> difficult to verify if the test is passing for the right >> reason. >> >> One thing that is obvious is that if we had some more >> specific types to line up with some of the more tested >> sections of the TCK, we could probably incorporate that into >> our test runners to check if the tests pass for the right >> reason. So say a PassivationCapableException subclass >> of WebBeansConfigurationException for the various tests that >> check for passivation capability (section 6.6.4). >> >> A slightly more interesting spin would be to annotate those >> exceptions with the related section of the spec. >> Basically something like the @SpecAssertion(section = >> "6.6.4", id = "bde") that the TCK uses. Seems like we >> could use this to line the exception up with the test >> assertion and give it the thumbs up or thumbs down in our >> harness. Users could also use it to figure out what >> part of the spec they need to read up on. >> >> >> -David >> >> >
