2016-11-01 11:50 GMT+01:00 Attila Magyar <m.magyar3@gmail.com>:
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.