Menu
▾
▴
mockobjects-java-users
|
From: Joe W. <jo...@tr...> - 2003-11-30 13:27:18
|
Hi mock objects people,
Java Open Source Programming, is now available to buy. I'm mentioning it
here because one of the main focal points of the book is
test-driven-development with mock objects. As well as explaining the
motivation and advantages of using mock objects, and of course how to
use the Java mock objects library, it illustrates how to use the process
behind mocks to drive the design of real world code, including with an
MVC framework and persistence layer.
Buy the book here:
http://www.amazon.com/exec/obidos/tg/detail/-/0471463620/
And see a review here:
http://www.theserverside.com/resources/article.jsp?l=JavaOpenSourceProgrammingBookReview
I apologise if you regard this message as spam - I consider it very
on-topic ;)
cheers
-Joe Walnes (co-author)
|
|
From: Eugene K. <eu...@md...> - 2003-11-30 16:10:45
|
Hi, 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 |
|
From: Nat P. <nat...@b1...> - 2003-11-30 19:27:09
|
Sure, post patches to the SF patch manager. Support for cglib is one of the
goals after the 1.0 release.
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!
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
> Hi,
>
> 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
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
|
|
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 >> >> |
|
From: Nat P. <nat...@b1...> - 2003-12-01 14:20:15
|
On Mon, 2003-12-01 at 05:53, Eugene Kuleshov wrote: > Nat Pryce wrote: > I faced that issue too. But my understanding was that I can and should > use "match" for such calls. So all "expect"-like calls will be in order > and all "match"-like calls can appear anywhere. Otherwise it will be just > not possible to handle different returns for the sequential calls > without or with the same parameters. The issue with an ordered InvocationDispatcher is that it makes tests too brittle. In general, one needs to specify that some calls are stubbed (matched in the 0.09 parlance), some are expected after others and some are expected but not in any order. Requiring that *all* calls are expected in a fixed order makes tests easy to break when code is changed over time. It is also quite a rare case -- I've only needed it when testing some quite baroque event announcement code. And even then it broke tests later! Our new approach is to provide an API that is used to specify that one invocation is expected to occur after another. This has the benefits that it highlights the ordering in the test and allows *partial* ordering, which gives much needed flexibility to the test code. Cheers, Nat. |
|
From: eu <eu...@md...> - 2003-12-01 15:22:39
|
Nat Pryce wrote: >> I faced that issue too. But my understanding was that I can and should >>use "match" for such calls. So all "expect"-like calls will be in order >>and all "match"-like calls can appear anywhere. Otherwise it will be just >>not possible to handle different returns for the sequential calls >>without or with the same parameters. >> >> >The issue with an ordered InvocationDispatcher is that it makes tests >too brittle. In general, one needs to specify that some calls are >stubbed (matched in the 0.09 parlance), some are expected after others >and some are expected but not in any order. Requiring that *all* calls >are expected in a fixed order makes tests easy to break when code is >changed over time. It is also quite a rare case -- I've only needed it >when testing some quite baroque event announcement code. And even then >it broke tests later! > >Our new approach is to provide an API that is used to specify that one >invocation is expected to occur after another. This has the benefits >that it highlights the ordering in the test and allows *partial* >ordering, which gives much needed flexibility to the test code. > > I see. That is sounds reasonable. In other words you are going to add chaining of expectations but not through invocation handler. Basically expectation on to be called after some other expectation. I can imagine something like that. exp1 = mock.expect( "method1", C.args(...)); exp2 = mock.expect( "method1", C.after( exp1, C.args(...))); exp2 = mock.expect( "method1", C.after( exp2, C.args(...))); ... This should be great. regards, Eugene PS: what about the 1.0 release? Is anybody know the answer yet? |
|
From: Steve F. <st...@m3...> - 2003-12-02 04:14:44
|
eu wrote: > I see. That is sounds reasonable. In other words you are going to add > chaining of expectations but not through invocation handler. Basically > expectation on to be called after some other expectation. I can imagine > something like that. > > exp1 = mock.expect( "method1", C.args(...)); > exp2 = mock.expect( "method1", C.after( exp1, C.args(...))); > exp2 = mock.expect( "method1", C.after( exp2, C.args(...))); exactly. > PS: what about the 1.0 release? Is anybody know the answer yet? no promises, but we might have a little time just before xmas. S. |
|
From: chris c. <drc...@ya...> - 2003-12-03 13:30:10
|
Hi Nat, I'm surprised that you found ordered Mocks brittle and unhelpful. In our code base we have 16 uses of OrderedMocks compared to 330 Mocks. This is a small percentage but I'd be loathe to give them up. We use OrderedMocks in "transactional type" code, that is in our transaction manager, and in our streaming code. We have n't found the tests were brittle and we (rewrote the error messages to be helpful )but looking at the code now this is plainly because the order that each of the methods is called always matters in these cases. I think you are right to go down the route of the API since if we still want to keep our OrderedMocks we will probably just hide the use of the API inside our own OrderedMock class, allowing us the best of both worlds. Cheers, Chris |
|
From: Steve F. <st...@m3...> - 2003-12-03 14:21:25
|
If we get to where we want to be, we should be able to provide ordered mocks with some sugar code. (promises, promises) S. chris cottee wrote: > I think you are right to go down the route of the API since if we still > want to keep our OrderedMocks we will probably just hide the use of the > API inside our own OrderedMock class, allowing us the best of both worlds. |
|
From: Mickael V. <mv...@ge...> - 2003-12-03 17:16:46
|
Hi everybody, I'm new to mockobjects and I try to understand to right way to use them. What I understound of mockobjects is that the good way to use them is to know which interactions it will have with your tested object , then make your mockobject respond to the tested object requests and record them, at the end of the test check that what has been recorded is correct. Is it true ? Is it so important to test interactions with mockobjects if your tested method returns the values you expected ? Is it correct sometimes to put code in your mockobject that does the same as the object it replaces instead of returning values. Sometimes it may be easier to code the functionnality than to emulate responses. In my case I test services called from a servlet, so I manipulate HttpRequest, HttpSession, ServletContext ... which I replaced with mockobjects. In this case I find it easier to code in the MockHttpSession the setAttribute and getAttribute methods than to guess which values will be asked if the service puts a lot of objects in the session and remove them. One service called by the servlet may have a lot of interactions with mockobjects and I can't use real objects as I don't have implementations. Do you think it is an acceptable use of mockobjects ? Or did I miss something ? I don't want to use Cactus which forces me to deploy. Maybe my use of mockobjects is too close to the the simulation of a web container ? Mickael |
|
From: Nat P. <nat...@b1...> - 2003-12-03 17:49:06
|
On Wed, 2003-12-03 at 16:55, Mickael Vera wrote: > Hi everybody, > > I'm new to mockobjects and I try to understand to right way > to use them. > > What I understound of mockobjects is that the good way to > use them is to know which interactions it will have with > your tested object , then make your mockobject respond to the > tested object requests and record them, at the end of the test > check that what has been recorded is correct. Is it true ? Not exactly. Put assertions into your mocks, so that your mocks test that they are being called correctly at the point that the call occurs. This will give you much more useful information when a failure occurs. The Mock Objects jargon for an assertion in a mock object is an "expectation": it defines what you expects to happen to the mock during the test. > Is it so important to test interactions with mockobjects if your > tested method returns the values you expected ? Yes, because the calls that an object makes to other objects around it (its side effects) are part of its behaviour, and therefore something that you should test. > Is it correct sometimes to put code in your mockobject > that does the same as the object it replaces instead of returning > values. Sometimes it may be easier to code the functionnality than > to emulate responses. No. If it is that hard to mock a response you must be doing something wrong. Why is it so hard to mock responses? Let the "testability" of your code guide its design and the code will become easier to maintain as a result. > In my case I test services called from a servlet, so I manipulate > HttpRequest, HttpSession, ServletContext ... which I replaced with > mockobjects. > In this case I find it easier to code in the MockHttpSession the > setAttribute > and getAttribute methods than to guess which values will be asked if > the service puts a lot of objects in the session and remove them. > One service called by the servlet may have a lot of interactions > with mockobjects and I can't use real objects as I don't have > implementations. It sounds like you are doing too much in one test. In particular, it sounds like you are trying to do integration testing rather than unit testing. Try testing each of those objects individually, and isolate them using mock objects. Cheers, Nat. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X