Smalltalk › Pharo › Pharo Smalltalk Developers

Mocks are missing in Pharo (from thread OSProcess is missing)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

30 messages Options

Sean P. DeNigris

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

Administrator

Denis Kudriashov wrote

You can look at features here:
http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html.

Ah, yes. I seem to recall one major hurdle for me was that each test needed everything wrapped in a block. Is that still the case? Could this be hidden somewhere in the mechanism? I also wonder whether Mocketry could be easily integrated with Phexample, as I really love the stacked test concept...

Denis Kudriashov wrote

BabyMock could not be treated as modern mock library just because it uses
symbols instead of normal message sends. Even C# and Java mocks are based
on normal messages.

In practice, I don't see why this makes such a big difference. What am I missing?

Cheers,
Sean

kilon.alios

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

I completely agree, I am all for minimal image and then the user should be able to install anything he/she wants through Catalog Browser, I think we need to make sure that the welcome text clearly illustrate this and that the new user is not confused. But that means that you the people who create project that are not in the main distribution make sure your project is on Catalog Browser and that there is a clear description of what it does.

Pharo already an excellent mechanism for installing packages. Just today I tried to install OSC library in Pharo 5 though monticello and configuration and I failed, then I tried the Catalog Browser and worked like a charm.

Big thanks to Esteban for this amazing tool is by far my favorite, second being GTSpotter of course ;)

On Mon, Oct 31, 2016 at 5:50 PM Sean P. DeNigris <[hidden email]> wrote:

Denis Kudriashov wrote
> You can look at features here:
> http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html.

Ah, yes. I seem to recall one major hurdle for me was that each test needed
everything wrapped in a block. Is that still the case? Could this be hidden
somewhere in the mechanism? I also wonder whether Mocketry could be easily
integrated with Phexample, as I really love the stacked test concept...

Denis Kudriashov wrote
> BabyMock could not be treated as modern mock library just because it uses
> symbols instead of normal message sends. Even C# and Java mocks are based
> on normal messages.

In practice, I don't see why this makes such a big difference. What am I
missing?

-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-missing-tp4920574p4920911.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Denis Kudriashov

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

In reply to this post by Sean P. DeNigris

2016-10-31 16:40 GMT+01:00 Sean P. DeNigris <[hidden email]>:

> You can look at features here:
> http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html.

Ah, yes. I seem to recall one major hurdle for me was that each test needed
everything wrapped in a block. Is that still the case? Could this be hidden
somewhere in the mechanism?

It was changed in version 3. Now blocks could be used to easily get multiple mocks (as block arguments) or to validate group of messages.

But it is not necessary. You can just work with separate mocks created by "Mock new". So you don't need blocks generally.

I thought it was seen in my blog post.

I also wonder whether Mocketry could be easily
integrated with Phexample, as I really love the stacked test concept...

Months ago I committed version of Phexample based on StateSpecs (new config in Phexample repo). So all projects are compatible.

Denis Kudriashov wrote
> BabyMock could not be treated as modern mock library just because it uses
> symbols instead of normal message sends. Even C# and Java mocks are based
> on normal messages.

In practice, I don't see why this makes such a big difference. What am I
missing?

For me it is just not readable, more code to write.

But also it makes tests fragile for refactorings. Try to change signature of method: new argument, remove argument, switch argument places. And tests will be broken (because mocks use symbols and not real messages).

Sean P. DeNigris

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

Administrator

Denis Kudriashov wrote

So you don't need blocks generally.
I thought it was seen in my blog post.

I guess I was confused by "Also there is way to get multiple mocks at once: [ :mockA :mockB | "your code here" ] runWithMocks"

Denis Kudriashov wrote

all projects are compatible.

Great!

Denis Kudriashov wrote

But also it makes tests fragile for refactorings

Ah, very good point!

Cheers,
Sean

Attila Magyar

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

In reply to this post by Denis Kudriashov

Denis Kudriashov wrote

BabyMock could not be treated as modern mock library just because it uses
symbols instead of normal message sends. Even C# and Java mocks are based
on normal messages.

Because they don't have symbols :). Ruby libraries often use symbols, last time I checked rspec mocks used it too. I think this is a matter of taste, it's not about being modern or not.

I like thinking about mock objects as tools for describing inter-object protocols (the visualisation tries to emphasize this aspect). The communication protocol between the object under test and its peers (mocks) is expressed in a descriptive language (this language can be changed in BabyMock quite easily). A narrator object (this is called Protocol in BabyMock2) speaks in the third person to describe the message exchange between the object cluster.
I don't like when expectations are set up in mocks directly any more, neither the should/should have notation. The GOOS book was a big influence on me at that time.

Denis Kudriashov

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

2016-11-01 11:50 GMT+01:00 Attila Magyar <[hidden email]>:

> BabyMock could not be treated as modern mock library just because it uses
> symbols instead of normal message sends. Even C# and Java mocks are based
> on normal messages.

Because they don't have symbols :).

They have strings. And first mock libraries used message names as strings. And any method rename broke tests.

Ruby libraries often use symbols, last
time I checked rspec mocks used it too. I think this is a matter of taste,
it's not about being modern or not.

Probably it looks not so bad with C-like syntax because everything is just function name and arguments inside parenthesise.

But with Smalltalk keywords syntax it looks horrible. I not believe that anybody would prefer writing:

protocol describe
once: socket
recv: #connectTo:port:waitForConnectionFor:

with: address with: port with: timeout.

over simple:

socket stub connectTo: address port: port waitForConnectionFor: timeout.

And as I said symbol(string) based version is not safe for refactorings.

I like thinking about mock objects as tools for describing inter-object
protocols (the visualisation tries to emphasize this aspect).

I agree with you.

The
communication protocol between the object

under test and its peers (mocks)
is expressed in a descriptive language (this language can be changed in
BabyMock quite easily). A narrator object (this is called Protocol in
BabyMock2) speaks in the third person to describe the message exchange
between the object cluster.
I don't like when expectations are set up in mocks directly any more,

It leads to more code which you will write again and again in your tests. And this code is nothing about actual business which tests describe.

In Mocketry there is also a guy who manages all specifications and collects all interactions but it's hidden from user.

With Mocketry I try to make mocks as simple as possible without losing power.

neither the should/should have notation. The GOOS book was a big influence
on me at that time.

Attila Magyar

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

They have strings. And first mock libraries used message names as strings

They are not the same. Method rename and find senders works with symbols but not with strings. Some rarely used refactorings might not work, although this is probably a technical limitation of the refactoring engine and not a conceptual one.

not believe that anybody would prefer writing

In Ruby this would look like something like this.

allow(socket).to receive(:connect).with(address, port, timeout) { do_something }

Not so different and many people use this. Probably lot more than the users of Mocketry + BabyMock together.

(Anyways probably I wouldn't use a mock library to stub an object like a socket. It is not my own type, too low-level abstraction. It results brittle tests no matter what syntax is used.)

It leads to more code which you will write again and again in your tests

If I have too many code for setting up expectations and mocks that is a clear clue that something went wrong in my test, and I rather have a mock library that makes this painful early on. It is really easy to make a mess with mock object based tests. This is why I still prefer jMock over any other mock object library (mockito, easymock) in Java. JMock is a highly opinionated library that deliberately doesn't support features like deep stubbing, partial mocking and other black magic stuffs. BabyMock follows a similar philosophy.

Denis Kudriashov

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

2016-11-01 18:27 GMT+01:00 Attila Magyar <[hidden email]>:

> They have strings. And first mock libraries used message names as strings

They are not the same. Method rename and find senders works with symbols but
not with strings. Some rarely used refactorings might not work, although
this is probably a technical limitation of the refactoring engine and not a
conceptual one.

No matter. This is what we have. And with message based approach this problem not exists at all.

2016-11-01 18:27 GMT+01:00 Attila Magyar <[hidden email]>:

> not believe that anybody would prefer writing

In Ruby this would look like something like this.

allow(socket).to receive(:connect).with(address, port, timeout) {
do_something }

This is exactly what I said: with C-like syntax it is normal but not with keyword messages.

Not so different and many people use this. Probably lot more than the users
of Mocketry + BabyMock together.

(Anyways probably I wouldn't use a mock library to stub an object like a
socket. It is not my own type, too low-level abstraction. It results brittle
tests no matter what syntax is used.)

It was just example where everybody could see agliness of string based approach.

> It leads to more code which you will write again and again in your tests

If I have too many code for setting up expectations and mocks that is a
clear clue that something went wrong in my test,

I use mocks in most unit tests. So in every test I will need to repeat all this code.

and I rather have a mock
library that makes this painful early on. It is really easy to make a mess
with mock object based tests. This is why I still prefer jMock over any
other mock object library (mockito, easymock) in Java. JMock is a highly
opinionated library that deliberately doesn't support features like deep
stubbing, partial mocking and other black magic stuffs. BabyMock follows a
similar philosophy.

Smalltalk is super powerful language which allows easily create and run tons of spaghetti code.

But with C++ it is sometime impossible to just compile spaghetti code. So C++ prevents programmers from writing bad code because without discipline you can't run your program.

So if you want to be good programmer choose C++.

(sorry for sarcasm)

Attila Magyar

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

And with message based approach this problem not exists at all.

Yes, it has different tradeoffs. For example you have to fill in the parameters even if you want to ignore them, or it is difficult (maybe impossibe) to express a parameter matcher that considers the relationship of multiple arguments (for example allow: mock recv: #a:b:; with: [:a :b | a > b]).

But I dont want to go off topic. I just disagree that this arbitrary and subjective feature makes something "modern" or not. Anyways, good luck with Mocketry.

Denis Kudriashov

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

2016-11-01 20:45 GMT+01:00 Attila Magyar <[hidden email]>:

Yes, it has different tradeoffs. For example you have to fill in the
parameters even if you want to ignore them, or it is difficult (maybe
impossibe) to express a parameter matcher that considers the relationship of
multiple arguments (for example /allow: mock recv: #a:b:; with: [:a :b | a >
b]/).

If you don't care about parameters you can use Any:

socket stub connectTo: Any port: Any waitForConnectionFor: Any.

Last case is a bit tricky of course but possible:

mock stub a: [:arg1 | a := arg1. true] b: [:b | a > b]

And it is easy to extend Mocketry for string based scenario:

mock stub message: #a:b: with: [:a :b | a > b].

But I don't see value for this.