> 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.
--
View this message in context:
http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-missing-tp4920574p4921035.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
