Re: [weld-dev] CDI TCK: InvocationContextTest:testGetTarget

On 2011-01-07, at 1:13 PM, Scott Ferguson wrote: > Marius Bogoevici wrote: >> On 2011-01-07, at 12:17 PM, Scott Ferguson wrote: >> >> >>> Marius Bogoevici wrote: >>> >>>> I don't see a particular issue with the test. The rules on what business method invocations are and aren't should make it clear that invocations on the instance acquired via getTarget() are intercepted, or, for that matter, decorated. Those are *not* business method invocations (in the same way as calls to 'this' are not business method invocations). >>>> >>> That behavior is not defined by any specification, unless you can find the section and cite it. >>> >> >> Section 7.2 of the CDI specification. > > Then there needs to be an explicit test for that behavior. Not an implicit one buried in another test. I agree with you here, but this wasn't the original point that has been raised - which was that the tests assume a particular implementation strategy and are therefore incorrect. The particular possibility of multiple reasons for failure opens the discussion on improving the granularity of the test harness and, yes, it would be better to have a separate test for self/getTarget() invocations. As a side note, I believe that the TCK may consider that the implementation under test is compliant as a whole, and combine multiple functionalities in a single test. So the assumption in this case would be that the behaviour of getTarget().getId() is correct - and assuming that does not necessarily mean that it performs implicit (or hidden) tests - it's just exercising a normal functionality of the framework. The salient point of my initial comment was that the expectation for invocations on an instance obtained via getTarget() to be neither intercepted nor decorated (as they are not business method calls) is correct with respect to the specification. With that in mind, the test by itself is not defective as initially stated, since any correct implementation will be able to pass it. Furthermore, I don't see a reason to change the test in order to accommodate implementations that use subclassing but allow for interception on this/getTarget()-acquired instances. In fact, such a change would allow for a faulty implementation (i.e. one that does not observe the self/getTarget() invocation and interception rules) to pass the TCK.