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 probab
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
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 #
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
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 o
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 sme
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
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. Than
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
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 Dem
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 :
> Hello,
>
> Thanks. Very nice library!
>
> I have a question: is it possible to expect a method to throw an Exception?
>
> I would like
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
cool!
On Wed, Mar 12, 2014 at 8:48 PM, Attila Magyar 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.
>
>
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.
Very cool stuff, indeed!
Ricky
On Wed, Mar 12, 2014 at 4:39 PM, Tudor Girba wrote:
> Beautiful work!
>
> Doru
>
>
> On Tue, Mar 11, 2014 at 12:30 PM, Attila Magyar wrote:
>
>> I'm pleased to announce the 2.0 version of BabyMock. BabyMock is a visual
>> mock object library that supports test-dri
Beautiful work!
Doru
On Tue, Mar 11, 2014 at 12:30 PM, Attila Magyar 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.
> T
It looks even cooler than before :)
Ben
On 11 Mar 2014, at 12:30, Attila Magyar 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 v
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 :
> 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
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
19 matches
Mail list logo
