Smalltalk › Pharo › Pharo Smalltalk Users

[ANN] BabyMock 2

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

19 messages Options

Attila Magyar

[ANN] BabyMock 2

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

Guillaume Larcheveque

Re: [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 <[hidden email]>:

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

Benjamin Van Ryseghem (Pharo)

Re: [ANN] BabyMock 2

In reply to this post by Attila Magyar

It looks even cooler than before :)

Ben

On 11 Mar 2014, at 12:30, Attila Magyar <[hidden email]> 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.

Tudor Girba-2

Re: [ANN] BabyMock 2

In reply to this post by Attila Magyar

Beautiful work!

Doru

On Tue, Mar 11, 2014 at 12:30 PM, Attila Magyar <[hidden email]> 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"

Richard Wettel-3

Re: [ANN] BabyMock 2

Very cool stuff, indeed!

Ricky

On Wed, Mar 12, 2014 at 4:39 PM, Tudor Girba <[hidden email]> wrote:

Beautiful work!

Doru

On Tue, Mar 11, 2014 at 12:30 PM, Attila Magyar <[hidden email]> 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"

Attila Magyar

Re: [ANN] BabyMock 2

Thanks for the nice words to everyone.

tinchodias

Re: [ANN] BabyMock 2

cool!

On Wed, Mar 12, 2014 at 8:48 PM, Attila Magyar <[hidden email]> 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.

demarey

Re: [ANN] BabyMock 2

In reply to this post by Attila Magyar

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 (5K) Download Attachment

Guillaume Larcheveque

Re: [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 <[hidden email]>:

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

demarey

Re: [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 <[hidden email]>:

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 (5K) Download Attachment

Attila Magyar

Re: [ANN] BabyMock 2

In reply to this post by demarey

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' ].

demarey

Re: [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 (5K) Download Attachment

Attila Magyar

Re: [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

demarey

Re: [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 (5K) Download Attachment

Attila Magyar

Re: [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.

demarey

Re: [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 MyClass>>methodA calls MyClass>>methodB and there is an error in MyClass>>methodB, 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 (5K) Download Attachment

Attila Magyar

Re: [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.

Sean P. DeNigris

Re: [ANN] BabyMock 2

Administrator

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

Attila Magyar

Re: [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.