2016-11-01 11:50 GMT+01:00 Attila Magyar <[email protected]>:
> > 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.
>
