Re: [Pharo-users] [ANN] BabyMock 2
Le 23 avr. 2014 à 22:25, Attila Magyar a écrit : Christophe Demarey wrote ... but sometimes, even in a well-designed class, you may need to test a very small part of this class, and in this case, you need a real object with some mocked methods. I assume that there is a method need to be tested, but it calls towards an other either public or private method of the same object. And you'd like to mock that second method. Am I understanding correctly? right Why can't just allow the first method to call the second one? Is it slow, complicated to setup or requires some external resource to execute? Does it help to extract the logic from the second method to an other object? Without a concrete example, I'm just speculating. My point here is just to test a method in isolation. If MyClassmethodA calls MyClassmethodB and there is an error in MyClassmethodB, I don't want to have the test on methodA failing but just the test on MethodB. With cascade testing, you will get a lot of failing tests and you need to investigate to find the culprit. As you said, if the class is well designed, it is not a big trade-off to unit test a small set of methods if they are short and related but I have the feeling that it would be good to be able to do that in some cases. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-users] [ANN] BabyMock 2
I made up an example because it makes easier to talk about this. Let's say, I want to test the #addAll: method of the OrderedCollection. If #addAll: is implemented as a loop that uses the #add: method (itemsToBeAdded do: [:each | self add: each]) then would you test the #addAll: isolated from the #add:? I think it would be a bad idea, because we're talking about an implementation detail. The #addAll: could have been implemented in a different way. Mocking the #add: couples the test to the current implementation and makes it brittle. If I change the implementation of the #addAll:, then the test will need to be changed as well, even if the functionality remained the same. You're right that if there is a bug in the #add: then 2 test cases will fail, instead of one (the localization is worse but the test is less brittle). But if I implement it in a different way, where the 2 methods have separated logic then only one will fail. Don't know if this example applies to you case or not. -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530p4756179.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] [ANN] BabyMock 2
Attila Magyar wrote I made up an example because it makes easier to talk about this An easy example which comes up for me a lot is when I want to pretend it's a certain DateAndTime. I'd like DateAndTime now to return a canned value. I know all the theoretical arguments about how if I change my domain object to really get the date from an atomic clock server, or a serial port light sensor connected to a sun dial, my test will fail because I've tied it to a duplicated implementation detail. However, I'm willing to accept that risk because: - in 5 years, I've only ever queried the current timestamp via DateAndTime now - the duplication can be controlled via abstraction e.g. MyTestCase#now: aDateAndTime - writing (pseudo-code) DateAndTime can receive:#now; answers: aDateAndTime: - is extremely easy - precludes me from muddying my domain class with a lot of test-only hooks, like #clock: and #clock or #clockClass: and #clockClass (multiplied by all such vectors) For sure, there are times when this could be abused. But the spirit of Smalltalk is to trust the programmer with the full power of the computer at every level (e.g. private methods are only a suggestion). - Cheers, Sean -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530p4756202.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] [ANN] BabyMock 2
This looks like a slightly different problem to me, where something has a hardcoded, hidden dependency (a global class object), which is not substitutable by design, but we want to replace it from the test to something that answers the canned value. I understand the practical arguments that probably nobody will ever want to replace the clock to an other one in production. But making the replaceable clock dependency is not the only option (though, making explicit that something is time dependent can be useful sometimes). Many times it is possible to get rid of the clock entirely at the current level and introduce a higher level abstraction that can respond to messages like, #isTrialPeriodExpired, #hasDayChangedFrom, #shouldCacheBeInvalidated depending on the domain. And this object can be mocked easily in test of its collaborator. Of course sometimes this is not possible or doesn't worth the effort. jb rainsberger had an interesting post about this http://blog.thecodewhisperer.com/2013/11/23/beyond-mock-objects/ Sean P. DeNigris wrote For sure, there are times when this could be abused. But the spirit of Smalltalk is to trust the programmer with the full power of the computer at every level (e.g. private methods are only a suggestion). This is a valid argument, but my point of view is different. I think the purpose of doing TDD is lost because of those shortcuts. It is easy to fall back to testing mode, and focus on the problem, how do I test something, instead of design something which is testable and therefore changeable without those shortcuts. -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530p4756230.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] [ANN] BabyMock 2
Hi, Le 17 avr. 2014 à 19:22, Attila Magyar a écrit : Hi Christophe, Sorry for my late response. You can use the following syntax to signal an error in response to an incoming message: protocol describe once: mock recv: #msg; signals: Error. I did not notice this one. Thanks! I have another point. Sometimes, I would like to test a method doing some other calls to methods of the same class. In this case, I would like to mock all the class methods but the method I would like to test. Do you sometime meet the same need? Is there a way to do that? Thanks, Christophe. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-users] [ANN] BabyMock 2
Hi Christophe, I'm not sure I fully understand, are you referring to partial mocking? Where you have a real object but with some mocked methods? If this is the case, then no, this is not supported. Some people consider this as a test smell, and I agree with them. Maybe the object under test is too big/complex/has multiple responsibilities, and extracting some parts from it could solve the problem. I haven't seen legitimitate use for partial mocking so far, where one couldn't solve the problem with redesign/refactoring in a better way. Until this happens I'd like to skip this feature. Attila -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530p4756008.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] [ANN] BabyMock 2
Le 23 avr. 2014 à 15:37, Attila Magyar a écrit : Hi Christophe, I'm not sure I fully understand, are you referring to partial mocking? Where you have a real object but with some mocked methods? If this is the case, then no, this is not supported. Some people consider this as a test smell, and I agree with them. Maybe the object under test is too big/complex/has multiple responsibilities, and extracting some parts from it could solve the problem. I haven't seen legitimitate use for partial mocking so far, where one couldn't solve the problem with redesign/refactoring in a better way. Until this happens I'd like to skip this feature. I understand your point of view and I have quite the same ... (I also had the same discussion with Guillaume) ... but sometimes, even in a well-designed class, you may need to test a very small part of this class, and in this case, you need a real object with some mocked methods. It is not crucial because you can test your class as a whole (if well designed, only a few methods are involved) but it prevents to test a smaller part. Then, maybe the work to support a real object with some mocked methods does not worth it. Best regards, Christophe smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-users] [ANN] BabyMock 2
Christophe Demarey wrote ... but sometimes, even in a well-designed class, you may need to test a very small part of this class, and in this case, you need a real object with some mocked methods. I assume that there is a method need to be tested, but it calls towards an other either public or private method of the same object. And you'd like to mock that second method. Am I understanding correctly? Why can't just allow the first method to call the second one? Is it slow, complicated to setup or requires some external resource to execute? Does it help to extract the logic from the second method to an other object? Without a concrete example, I'm just speculating. -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530p4756105.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] [ANN] BabyMock 2
I think you can have your mock send an exception by using #answers:aBlock and signal the exception in the block 2014-04-08 15:58 GMT+02:00 Christophe Demarey christophe.dema...@inria.fr: Hello, Thanks. Very nice library! I have a question: is it possible to expect a method to throw an Exception? I would like something like: protocol describe once: mock recv: #aMethod ; signal: anError. I did not find anything in the documentation. I don't want to test that the mock signals an error but I want to test a code that needs to take into account an exception. Best regards, Christophe. Le 11 mars 2014 à 12:30, Attila Magyar a écrit : I'm pleased to announce the 2.0 version of BabyMock. BabyMock is a visual mock object library that supports test-driven development. This version has a new syntax which is incompatible with the old version. Therefore it has a new repository http://smalltalkhub.com/#!/~zeroflag/BabyMock2 (BabyMock 1 is still available at its old location, but in the future I'd to focus on the development of BabyMock2, so don't expect too many changes regarding the old version). Changes in 2.0 - A new, extensible DSL (no more should/can) - Improved error messages, history of messages, detailed information about argument mismatches - An improved, Spec based GUI - Clicking on a mock opens an inspector on the expectations - Clicking on a message opens an inspector on the message - Object methods can be mocked by defaults - Blocks can be executed after receiving a message by the mock. The block has access to the arguments of the incoming message. - Any argument matcher - Cleanups and simplifications in the code I hope you don't mind the changes regarding the syntax. Personally I think it has lot more pros than cons. More information http://smalltalkhub.com/#!/~zeroflag/BabyMock2 p.s. It needs Pharo3.0. Attila -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- *Guillaume Larcheveque*
Re: [Pharo-users] [ANN] BabyMock 2
Thanks Guillaume. It works well. With BabyMock2, the syntax is = aBlock Le 9 avr. 2014 à 11:13, Guillaume Larcheveque a écrit : I think you can have your mock send an exception by using #answers:aBlock and signal the exception in the block 2014-04-08 15:58 GMT+02:00 Christophe Demarey christophe.dema...@inria.fr: Hello, Thanks. Very nice library! I have a question: is it possible to expect a method to throw an Exception? I would like something like: protocol describe once: mock recv: #aMethod ; signal: anError. I did not find anything in the documentation. I don't want to test that the mock signals an error but I want to test a code that needs to take into account an exception. Best regards, Christophe. Le 11 mars 2014 à 12:30, Attila Magyar a écrit : I'm pleased to announce the 2.0 version of BabyMock. BabyMock is a visual mock object library that supports test-driven development. This version has a new syntax which is incompatible with the old version. Therefore it has a new repository http://smalltalkhub.com/#!/~zeroflag/BabyMock2 (BabyMock 1 is still available at its old location, but in the future I'd to focus on the development of BabyMock2, so don't expect too many changes regarding the old version). Changes in 2.0 - A new, extensible DSL (no more should/can) - Improved error messages, history of messages, detailed information about argument mismatches - An improved, Spec based GUI - Clicking on a mock opens an inspector on the expectations - Clicking on a message opens an inspector on the message - Object methods can be mocked by defaults - Blocks can be executed after receiving a message by the mock. The block has access to the arguments of the incoming message. - Any argument matcher - Cleanups and simplifications in the code I hope you don't mind the changes regarding the syntax. Personally I think it has lot more pros than cons. More information http://smalltalkhub.com/#!/~zeroflag/BabyMock2 p.s. It needs Pharo3.0. Attila -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Guillaume Larcheveque smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-users] [ANN] BabyMock 2
Hello, Thanks. Very nice library! I have a question: is it possible to expect a method to throw an Exception? I would like something like: protocol describe once: mock recv: #aMethod ; signal: anError. I did not find anything in the documentation. I don't want to test that the mock signals an error but I want to test a code that needs to take into account an exception. Best regards, Christophe. Le 11 mars 2014 à 12:30, Attila Magyar a écrit : I'm pleased to announce the 2.0 version of BabyMock. BabyMock is a visual mock object library that supports test-driven development. This version has a new syntax which is incompatible with the old version. Therefore it has a new repository http://smalltalkhub.com/#!/~zeroflag/BabyMock2 (BabyMock 1 is still available at its old location, but in the future I'd to focus on the development of BabyMock2, so don't expect too many changes regarding the old version). Changes in 2.0 - A new, extensible DSL (no more should/can) - Improved error messages, history of messages, detailed information about argument mismatches - An improved, Spec based GUI - Clicking on a mock opens an inspector on the expectations - Clicking on a message opens an inspector on the message - Object methods can be mocked by defaults - Blocks can be executed after receiving a message by the mock. The block has access to the arguments of the incoming message. - Any argument matcher - Cleanups and simplifications in the code I hope you don't mind the changes regarding the syntax. Personally I think it has lot more pros than cons. More information http://smalltalkhub.com/#!/~zeroflag/BabyMock2 p.s. It needs Pharo3.0. Attila -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-users] [ANN] BabyMock 2
cool! On Wed, Mar 12, 2014 at 8:48 PM, Attila Magyar m.magy...@gmail.com wrote: Thanks for the nice words to everyone. -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530p4748878.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] [ANN] BabyMock 2
Beautiful work! Doru On Tue, Mar 11, 2014 at 12:30 PM, Attila Magyar m.magy...@gmail.com wrote: I'm pleased to announce the 2.0 version of BabyMock. BabyMock is a visual mock object library that supports test-driven development. This version has a new syntax which is incompatible with the old version. Therefore it has a new repository http://smalltalkhub.com/#!/~zeroflag/BabyMock2 (BabyMock 1 is still available at its old location, but in the future I'd to focus on the development of BabyMock2, so don't expect too many changes regarding the old version). Changes in 2.0 - A new, extensible DSL (no more should/can) - Improved error messages, history of messages, detailed information about argument mismatches - An improved, Spec based GUI - Clicking on a mock opens an inspector on the expectations - Clicking on a message opens an inspector on the message - Object methods can be mocked by defaults - Blocks can be executed after receiving a message by the mock. The block has access to the arguments of the incoming message. - Any argument matcher - Cleanups and simplifications in the code I hope you don't mind the changes regarding the syntax. Personally I think it has lot more pros than cons. More information http://smalltalkhub.com/#!/~zeroflag/BabyMock2 p.s. It needs Pharo3.0. Attila -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-users] [ANN] BabyMock 2
Very cool stuff, indeed! Ricky On Wed, Mar 12, 2014 at 4:39 PM, Tudor Girba tu...@tudorgirba.com wrote: Beautiful work! Doru On Tue, Mar 11, 2014 at 12:30 PM, Attila Magyar m.magy...@gmail.comwrote: I'm pleased to announce the 2.0 version of BabyMock. BabyMock is a visual mock object library that supports test-driven development. This version has a new syntax which is incompatible with the old version. Therefore it has a new repository http://smalltalkhub.com/#!/~zeroflag/BabyMock2 (BabyMock 1 is still available at its old location, but in the future I'd to focus on the development of BabyMock2, so don't expect too many changes regarding the old version). Changes in 2.0 - A new, extensible DSL (no more should/can) - Improved error messages, history of messages, detailed information about argument mismatches - An improved, Spec based GUI - Clicking on a mock opens an inspector on the expectations - Clicking on a message opens an inspector on the message - Object methods can be mocked by defaults - Blocks can be executed after receiving a message by the mock. The block has access to the arguments of the incoming message. - Any argument matcher - Cleanups and simplifications in the code I hope you don't mind the changes regarding the syntax. Personally I think it has lot more pros than cons. More information http://smalltalkhub.com/#!/~zeroflag/BabyMock2 p.s. It needs Pharo3.0. Attila -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-users] [ANN] BabyMock 2
Thanks for the nice words to everyone. -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530p4748878.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] [ANN] BabyMock 2
Cool!!! I use BabyMock a lot and I'm curious to see the new DSL. Thanks a lot for your work. 2014-03-11 12:30 GMT+01:00 Attila Magyar m.magy...@gmail.com: I'm pleased to announce the 2.0 version of BabyMock. BabyMock is a visual mock object library that supports test-driven development. This version has a new syntax which is incompatible with the old version. Therefore it has a new repository http://smalltalkhub.com/#!/~zeroflag/BabyMock2 (BabyMock 1 is still available at its old location, but in the future I'd to focus on the development of BabyMock2, so don't expect too many changes regarding the old version). Changes in 2.0 - A new, extensible DSL (no more should/can) - Improved error messages, history of messages, detailed information about argument mismatches - An improved, Spec based GUI - Clicking on a mock opens an inspector on the expectations - Clicking on a message opens an inspector on the message - Object methods can be mocked by defaults - Blocks can be executed after receiving a message by the mock. The block has access to the arguments of the incoming message. - Any argument matcher - Cleanups and simplifications in the code I hope you don't mind the changes regarding the syntax. Personally I think it has lot more pros than cons. More information http://smalltalkhub.com/#!/~zeroflag/BabyMock2 p.s. It needs Pharo3.0. Attila -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- *Guillaume Larcheveque*
Re: [Pharo-users] [ANN] BabyMock 2
It looks even cooler than before :) Ben On 11 Mar 2014, at 12:30, Attila Magyar m.magy...@gmail.com wrote: I'm pleased to announce the 2.0 version of BabyMock. BabyMock is a visual mock object library that supports test-driven development. This version has a new syntax which is incompatible with the old version. Therefore it has a new repository http://smalltalkhub.com/#!/~zeroflag/BabyMock2 (BabyMock 1 is still available at its old location, but in the future I'd to focus on the development of BabyMock2, so don't expect too many changes regarding the old version). Changes in 2.0 - A new, extensible DSL (no more should/can) - Improved error messages, history of messages, detailed information about argument mismatches - An improved, Spec based GUI - Clicking on a mock opens an inspector on the expectations - Clicking on a message opens an inspector on the message - Object methods can be mocked by defaults - Blocks can be executed after receiving a message by the mock. The block has access to the arguments of the incoming message. - Any argument matcher - Cleanups and simplifications in the code I hope you don't mind the changes regarding the syntax. Personally I think it has lot more pros than cons. More information http://smalltalkhub.com/#!/~zeroflag/BabyMock2 p.s. It needs Pharo3.0. Attila -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.