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
On 04-Jan-24 12:47:16 AM, christoph.thiede@student.hpi.uni-potsdam.de wrote:
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.squeakfo...).
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.squeakfoun... 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 https://github.com/hpi-swa-lab/squeak-inbox-talk