[squeak-dev] The Inbox: Tests-cwp.281.mcz

Colin Putney colin at wiresong.com
Wed Jan 1 22:26:06 UTC 2014


On Wed, Jan 1, 2014 at 4:31 PM, Frank Shearar <frank.shearar at gmail.com>wrote:


> > Item was added:
> > + ----- Method: BindingPolicyTest>>testAddHonorsEnvironment (in category
> 'tests') -----
> > + testAddHonorsEnvironment
> > +       | binding other |
> > +       other := Environment withName: #other.
> > +       policy := self bindingPolicyWithNamePolicy: AllNamePolicy new.
> > +       binding := #Griffle => value.
> > +       policy binding: binding addedTo: other notify: self.
> > +       self assert: notified = nil!
>
> I think I've established my reputation as a loud lover of
> #assert:equals: :) Just sayin'.
>

I'm too used to the debugger, I guess. Using #assert:equals: feels like
JUnit's work around for the fact that you get an error message, not a
debugger when the test fails. But now that we have automated testing, we
need the work around too!


> What I often do is set these kinds of variables - variables that show
> that some side effect took place - to some obviously wrong value. In
> this case, you could set notifier := #notCalled in the #setUp.
>

Ah, nice. I'll make that tweak.


> I can't figure out what this test _does_ though: when you say that add
> honours Environment, you mean that it only adds the binding if the
> addedTo: environment matches the policy's environment, and we know
> this because the notifier isn't called?


Yes, exactly. The policy responds to changes in a particular environment,
and directs another environment to take action in response. So imports
react to events in the "upstream" environment, and tell the local
environment to add or remove bindings in to stay in sync. Exports react to
changes in *this* environment, and notify the "downstream" environments
about them.


> > Item was added:
> > + ----- Method: BindingPolicyTest>>testRemoveHonorsEnvironment (in
> category 'tests') -----
> > + testRemoveHonorsEnvironment
> > +       | binding other |
> > +       other := Environment withName: #other.
> > +       policy := self bindingPolicyWithNamePolicy: AllNamePolicy new.
> > +       binding := #Griffle => value.
> > +       policy binding: binding removedFrom: other notify: self.
> > +       self assert: notified = nil!
>
> Same thing as #testAddHonorsEnvironment?
>

Yes, but for a binding removed, rather than added.


> > Item was changed:
> >   ----- Method:
> EnvironmentTest>>testImportAddingPrefixResolvesUndeclared (in category
> 'import tests') -----
> >   testImportAddingPrefixResolvesUndeclared
> >         | binding foreign |
> >         foreign := Environment withName: #Foreign.
> >         foreign exportSelf.
> > +       foreign bind: #Griffle to: value.
> > +       binding := env undeclare: #XXGriffle.
>
> I like this. Nice & explicit language.


I'm hoping to build up a simple protocol for this stuff, so we can't
replace all the dictionary manipulation that's scattered around the image
with more semantically explicit messages. See, for example #declarationOf:.



> Item was changed:
> >   ----- Method: EnvironmentTest>>testImportAliases (in category 'import
> tests') -----
> >   testImportAliases
> >         | foreign v2 v3 |
> >         foreign := Environment withName: #Foreign.
> >         foreign exportSelf.
> >         foreign at: #Griffle put: value.
> >         foreign at: #Nurp put: (v2 := Object new).
> >         foreign at: #Ziffy put: (v3 := Object new).
>
> Shouldn't these be #bind:to: now?
>

Yeah... missed updating them.


>
> > +       env from: foreign import: {#Nurp -> #Plonk. #Ziffy -> #Wiffy}.
> > -       env from: foreign import: {#Plonk -> #Nurp. #Wiffy -> #Ziffy}.
>
> I find this hard to understand. So the Array of Associations looks
> like it says "when you see Ziffy, interpret that as if you saw Wiffy",
> or "map Ziffy to Wiffy". Oh. It says "when you import foreign, map
> foreign's Ziffy to env's (new) Wiffy. OK, that makes sense.


I think I had it backwards in the previous version, because the lazy
lookups make all the name transformations happen the wrong way around. It
should match the simple version of the import. So this:

env from: foreign import: #Wiffy

means pretty much what it says, "import #Wiffy from foreign". The renaming
version is (now) similar:

env from: foreign import: #Wiffy -> #Ziffy

meaning, "import foreign's #Wiffy, but rename it to #Ziffy"

I guess that's the opposite of what you concluded.


> >   ----- Method: EnvironmentTest>>testImportWritable (in category 'import
> tests') -----
> >   testImportWritable
> >         | foreign binding |
> >         foreign := Environment withName: #Foreign.
> >         foreign exportSelf.
> > +       foreign bind: #Griffle to: 'v1'.
> > +       env from: foreign import: #Griffle -> #Plonk.
> > -       foreign at: #Griffle put: 'v1'.
> > -       env from: foreign import: #Plonk -> #Griffle.
> >         binding := env bindingOf: #Plonk.
> >         binding value: 'v2'.
> > +       self assert: (foreign declarationOf: #Griffle) value = 'v2' !
> > -       self assert: (foreign bindingOf: #Griffle) value == 'v2' !
>
>

> I realise this is existing behaviour, but I'm not so keen on
> sub-environments being able to tinker with parent environments'
> bindings. What's the use case here? It means an Environment can't be
> used as a sandbox.


This is really for Globals. It just ensures that all environments that
share a global will see the same value, regardless of what it's called.


> Item was added:
> > + ----- Method: EnvironmentTest>>testUndeclare (in category 'binding
> tests') -----
> > + testUndeclare
> > +       | one two |
> > +       one := env undeclare: #Griffle.
> > +       two := env bindingOf: #Griffle.
> > +       self assert: one == two.
> > +       self assert: one class == Global!
>
> Ah. This shows that you can always add new undeclared stuff to an
> environment. The name of the test didn't tell me that :/.


Well, it mostly tests that #undeclare: exists and works as expected: it
answers the same binding the subsequent calls to #bindingOf will answer.


> Also, is it
> part of the API that one value isNil?


It should be, yeah. Oversight on my part.


>
> Minor nit: one of these tests says "BecomeSomething" and the other
> says "BecomesSomething".


Will fix.


> > Item was changed:
> > + ----- Method: MCClassDefinitionTest>>testLoadAndUnload (in category
> 'as yet unclassified') -----
>
> So all this noise in the Monticello tests is because there are two
> Tests-fbs.280 - one in trunk, and one in the inbox. Fun times. The one
> in the inbox changes the MC tests to load definitions into an
> Environment that's then thrown away after the test runs. This avoids
> MC mucking around with global state.
>

Ugh, sorry about that. Didn't notice the extra changes.


> The changes have been sitting in the Inbox for a week, but given
> Colin's big chunk of stuff landing in the Inbox, let's review it, push
> to trunk when ready, and then I'll update my MC test hacking, and
> resubmit.
>

I've been meaning to review that, but I wanted to get these changes done
before I forget how they work. :-)

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140101/a80decb4/attachment-0001.htm


More information about the Squeak-dev mailing list