On 7 Jan 2011, at 21:01, Marius Bogoevici wrote: > > 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.
Agreed, the testsuite can clearly assume that other parts of the spec are correctly implemented, regardless of whether there is a test for that part of the spec. However, we should add a test for this, so Marius or Scott do you want to file a Feature Request for that? _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
