Very cool stuff, indeed! Ricky On Wed, Mar 12, 2014 at 4:39 PM, Tudor Girba <tudor@tudorgirba.com> wrote:

Beautiful work!

Doru

On Tue, Mar 11, 2014 at 12:30 PM, Attila Magyar <m.magyar3@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"

cool! On Wed, Mar 12, 2014 at 8:48 PM, Attila Magyar <m.magyar3@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.

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.Demarey@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*

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. Note that the Error is a class not an instance. Or alternatively you can execute an arbitrary block like Guillaume suggested. protocol describe once: mock recv: #msg; => [ Error signal: 'asdf' ]. -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530p4755157.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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.

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.

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.

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.