Hi all, hi Eliot,


> > What do you mean by this? Such a TestCase receiver environment should definitively be not the default, this would be very confusing!

>
> Oh interesting! What kind of confusion do you foresee? I had just imagined that the only visible-ish change would be availability of TestCase instance-side methods on the "self" in the Workspace.

SUnit is just one of so many domains. Someone else might want to evaluate things in the context of Transcript (self showln: 'foo') or any other console host (name := self input: 'Your name?'. self output: 'Hello ' , name) etc. pp....

@AssertResults via reflection:

Highly interesting topic! I already had some thoughts about this last summer and I have an image containing some stubs for it. My basic idea was to pass only blocks to the #assert: method that can more easily be decompiled, reevaluated, and whatever you wish. One then could identify the receiver "X" of the last message from the assertion block "X y: Z" and transform this message send into "X assert: #y: with: {Z}", where #assert:with: would be implemented on Object and could dispatch the assertion selector to several extension methods. This would allow us, for example, to write
self assert: [myList noneSatisfy: [:ea | ea hasPlung]]
and TestCase >> #assert:, under the hood, would this transform into
self assert: [myList assert: #noneSatisfy: with: [:ea | ea even]]
and then, an extension method á la #assertNoneSatisfy: could be called from #assert:with: and instead of only signaling a generic AssertionFailure, we could see something like:

<http://www.hpi.de/>
"No object in myList should satisfy [:ea | ea even], but 4 (at index 2) does satisfy."

As a plus, every package/framework developer could simply add support for customized AssertionFailures by overriding that #assert:with: and handling custom test selectors.
If we wanted to go one step further, we could even try to detect nested calls, e.g.:
self assert: [(myList anySatisfy: [:ea | ea hasPlung]]) and: [myList size even]]
"myList should satisfy myList size even but did not"
"myList should satisfy myList size even but size is 5"

Ha, what a dream! And it shouldn't be terribly complicated, too ... For more inspiration, take a look at FluentAssertions for C#. :-)
(If anyone asks: I never realized this projects because I did not know what to do if one of these parameters has side effects, e.g. when a block is called. Any ideas?)

Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob at resfarm.de>
Gesendet: Montag, 12. Oktober 2020 21:27:48
An: squeak-dev at lists.squeakfoundation.org
Betreff: Re: [squeak-dev] assert:equals: in Object

Eliot Miranda-2 wrote
> - appealing to the SUnit community to reverse the order of arguments to
> assert:equals:, plus a rewrite rule that reversed the obvious cases where
> the first argument is a literal constant.

For what it is worth, Pharo has just swapped the parameters... which makes
all "portable" test cases awkward.



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201012/67d83c95/attachment.html>