+1 how to start? 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.
LieGrue, strub --- 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 > >
