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
