From: Eugene K. <eu...@md...> - 2003-12-01 05:53:32
|
Nat Pryce wrote: >Sure, post patches to the SF patch manager. Support for cglib is one of the >goals after the 1.0 release. > > Ok. I'll will do it this week. There are some minor/low-level issue that I'd like to investigate more. By the way, what is the timeframe for release 1.0? I really curious what kind of cglib support are you planning? New version of cglib have no dependency on heavy BCEL and using ASM instead, the beta I've used in that hack is quite stable. >As for the OrderedInvocationDispatcher, experience has shown us that it is >not a good idea. No matter what ordering constraints are expected in the >test, there are methods that can be called on an object at any time, such as >toString. Often these are called within the test framework when creating >error messages and such. If an OrderedInvocationDispatcher is used, calling >these "out-of-order" methods will create obscure error messages. If the >method was called while generating an error message, the final error message >will hide the actual error, making it hard to detect what went wrong with >the code. So, our approach now is to use an unordered invocation dispatcher >and to explicitly define which expected calls have a required ordering. The >definition of call order is not yet implemented, but will be very soon! > > I faced that issue too. But my understanding was that I can and should use "match" for such calls. So all "expect"-like calles will be in order and all "match"-like calls can apper anywhere. Otherwise it will be just not possible to handle differerent returns fir the sequential calls without or with the same parameters. regards, Eugene >Cheers, > Nat. >_______________________ >Dr. Nathaniel Pryce >B13media Ltd. >http://www.b13media.com >+44 (0)7712 526 661 > >----- Original Message ----- >From: "Eugene Kuleshov" <eu...@md...> >Cc: "'Mockobjects-Java-Dev'" <moc...@li...>; >"'Mockobjects-Java-Users'" <moc...@li...> >Sent: Sunday, November 30, 2003 4:10 PM >Subject: [MO-java-dev] Cretion of the dynamic mocks for classes vs. >interfaces > >>i, >> >> I've implemented a feature that allows to pass class to Mock object >>constructor (present functionality was only working for interfaces) and >>even use non default constructor. That was possible because of cglib. >>The affected class is Mock, and I've added CoreInstanceMock and >>OrderedInvocationDispatcher. >> >> Is anyone interesed? >> >> regards, >> Eugene >> >> |