Hi Christoph,
Exactly - both issues have been bothering me too :))
1. The order of #assert: expected equals: actual
I understand your concern re readability of convoluted asserts but most of them are simple and then the English order is definitely more readable.
As backward compatibility is an issue here I wouldn't mind adding sibling methods like e.g.
should: actual equal: expected
^ self
assert: expected
equals: actual
description: nil
reversing the order. (or #assert: actual answers: expected, etc)
2. The ability to move tests to and from the Workspace
Being able to bind self to an object of your choice sounds really attractive (not that I know how to do that or what challenges it brings). Funny, I never realized using the Inspector's evaluator field is such a simple workaround - thanks for bringing this thread up!
Alas, I can't comment on your metaprogramming vision but it sounds like a quite complex exercise (likely due to my lack of tools and experience though ;) ).
Best!
Jaromir
Hi Jaromir,
On 2024-01-03T22:42:12+00:00, mail@jaromir.net wrote:
> Hi Christoph,
>
> On 02-Jan-24 8:10:55 PM, christoph.thiede(a)student.hpi.uni-potsdam.de
> wrote:
>
> >+1 provided that no one objects against this breaking change after a
> >couple of days (see
> >https://lists.squeakfoundation.org/archives/list/squeak-dev(a)lists.squeakfoundation.org/thread/FAPYVA4R2V42KTNJTTW5EKUUESR6V34G/).
> >
> >And you omitted two chances for #assert:equals: again. But maybe that's
> >a style questions only. After all, we are obfuscating our tests and
> >testing framework by duplicating basic protocols from the rest of the
> >systems, for the sole purpose of generating better assertion error
> >messages. :-) I agree with Eliot when he suggested a couple of years
> >ago to use metaprogramming for generating these messages instead (I can
> >try to find that thread again when you're interested).
>
> Yes please, if you don't mind. Thanks!
Here you are:
https://lists.squeakfoundation.org/archives/list/squeak-dev@lists.squeakfoundation.org/message/XGPZMKCAQJGIUYDX43G3TVWFVEFK2GJM/
Most of the thread revolves around better assertion concepts, but I have linked to the particular message in which I described my vision based on blocks and metaprogramming. I guess the issue of side effects when reevaluating assertion blocks could be solved by using a SimulationStudio Sandbox. :-)
Best,
Christoph
>
> >
> >
> >Best,
> >Christoph
> >
> >---
> >Sent from Squeak Inbox Talk
> ><https://github.com/hpi-swa-lab/squeak-inbox-talk>
> >
> >On 2024-01-02T11:28:09+00:00, commits(a)source.squeak.org wrote:
> >
> > > A new version of KernelTests was added to project The Inbox:
> > > http://source.squeak.org/inbox/KernelTests-jar.449.mcz
> > >
> > > ==================== Summary ====================
> > >
> > > Name: KernelTests-jar.449
> > > Author: jar
> > > Time: 2 January 2024, 12:28:08.184411 pm
> > > UUID: decf5a85-87ad-5849-b692-ee28940eab41
> > > Ancestors: KernelTests-jar.448
> > >
> > > Test if #return:from: correctly handles returns to nil contexts
> > >
> > > =============== Diff against KernelTests-jar.448 ===============
> > >
> > > Item was added:
> > > + ----- Method: ContextTest>>testBlockCannotReturnToNil (in category
> >'tests') -----
> > > + testBlockCannotReturnToNil
> > > + "Test if #return:from: correctly handles returns to dead or nil
> >contexts."
> > > +
> > > + | context nextContext |
> > > + context := [] asContext.
> > > +
> > > + "assert p is at the last instruction, i.e. a return, and is
> >about to return to a nil context"
> > > + self assert: context method selector = thisContext method
> >selector.
> > > + self assert: context sender isNil.
> > > + self assert: context willReturn.
> > > + self assert: context atEnd.
> > > +
> > > + nextContext := context step. "step into a return to a nil
> >sender"
> > > +
> > > + self assert: nextContext method selector = #cannotReturn:!
---
Sent from Squeak Inbox Talk