Mocketry

First of all: Thanks to dionis for provding useful package comments
to BehaviorMockup:

        --- Blessed: Released
        --- By: dionis
        --- On: 02/18/2008 14:42:09.000
        This is last release. Now you should use Mocketry

This makes following developments very easy :-)

To get the MocketryTests to pass I had to make three changes to my
image:

1. Add
        SequenceableCollection>>equivalentTo: aCollection
       
        self size = aCollection size ifFalse: [^false].
        ^(self allSatisfy: [:each | aCollection includes: each]) and:
                        [aCollection allSatisfy: [:each | self includes: each]]

2. Import TestFailure
        Smalltalk.SMock defineClass: #ProxyTest
                superclass: #{SUnit.TestCase}
                indexedType: #none
                private: false
                instanceVariableNames: ''
                classInstanceVariableNames: ''
                imports: '
                        private XProgramming.SUnit.TestFailure
                        '
                category: 'STMock-Test'

3. Import TestFailure
        Smalltalk.SMock defineClass: #MockTest
                superclass: #{SUnit.TestCase}
                indexedType: #none
                private: false
                instanceVariableNames: 'mock proxy '
                classInstanceVariableNames: ''
                imports: '
                        private XProgramming.SUnit.TestFailure
                        '
                category: 'STMock-Test'

Regards,
s.

A buglet:

SpecDSLAcceptanceTests>>testStrictlySatisfy reads "should lenient satisfy"
where it ought to be "should strictly satisfy".

s.

Stefan Schmiedl wrote:
Urghhh!

If we are going to treat ordered collections as unordered collections
could we
 pretty please reveal that in the selector name. E.g. #isSameSetAs:


It is not a problem if you use ambiguous selectors names in a limited
domain, because that domain will imply its semantics. However extending
my base library in such a way (by a test package no less!) is playing
with fire in paces I'd rather see discouraged.



I notice that the RBrowserHistory also gives us an equivalentTo: but
this time on Collection.

R
-




--
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************

On Wed, 20 Feb 2008 11:43:35 +0100
Reinout Heeck <[hidden email]> wrote:

Here, have a bucket ;-) I hope I didn't spoil your appetite for lunch.

> If we are going to treat ordered collections as unordered collections
> could we pretty please reveal that in the selector name. E.g. #isSameSetAs:

This would have to be changed in Mocketry, then. My quick-and-dirty fix
ended up where it is, because the debugger's "Define Method" put the
stub into OrderedCollection after the first failure. Then Mocketry used
equivalentTo: on arrays, so I pushed the method up until the test
passed.

> It is not a problem if you use ambiguous selectors names in a limited
> domain, because that domain will imply its semantics. However extending
> my base library in such a way (by a test package no less!) is playing
> with fire in paces I'd rather see discouraged.

Well, I've been guessing at what the intention of equivalentTo:  could
have been. It might as well have obeyed the sequence of elements in the
Mocketry's original image. I wouldn't know.

> I notice that the RBrowserHistory also gives us an equivalentTo: but
> this time on Collection.

ah... I remembered seeing an equivalentTo: somewhere, but could not
find it anymore. RBrowserHistory not being in my current image explains
this.

Regards,
s.

Stefan Schmiedl wrote:

The implementation of  RBrowserHistory seems equivalent to yours :-)


Are you willing to get this rename pushed out, both in Mocketry and
RBrowserHistory? I don't know how to contact the author of #equivalenTo:
(yet).
Another question is in what package #isSameSetAs: should live...




TIA!

Reinout
-------

On Wed, 20 Feb 2008 12:40:49 +0100
Reinout Heeck <[hidden email]> wrote:

> Stefan Schmiedl wrote:
> > ah... I remembered seeing an equivalentTo: somewhere, but could not
> > find it anymore. RBrowserHistory not being in my current image explains
> > this.
>
> The implementation of  RBrowserHistory seems equivalent to yours :-)

yeah, well, I'm learning by reading obviously :-)

> Are you willing to get this rename pushed out, both in Mocketry and
> RBrowserHistory? I don't know how to contact the author of #equivalenTo:
> (yet).
> Another question is in what package #isSameSetAs: should live...

I'm the wrong person to ask... I'm not the author of Mocketry,
RBrowserHistory, just a happy kid messing with stuff :-)

s.