[squeak-dev] assert:equals: in Object

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Fri Oct 9 13:13:24 UTC 2020


Hi Marcel,


> still, it would be a shame if we would remove #assert:(description:) from Object, too. Then we couldn't document invariants in code anymore. So many trade-offs! :-O


<http://www.hpi.de/>
Yes, I absolutely agree with that. Production assertions are a useful feature. But compared to SUnit, they are not meant to fail at any time, and if they fail, they should do so during development only, so I don't think we have to optimize the meaningfulness of AssertionFailure messages (as opposed to TestFailures. See https://github.com/hpi-swa/smalltalkCI/issues/478 :-)).

> As you suggested, this could be better solved at the tool level. The "self" binding in workspaces has great potential. Bind it to an example test case, and this would work. :-)

I do indeed think there is much potential for new ideas (and this would finally show me a reason why variable bindings can be useful as an orthogonal concept to instance variables). But how can we avoid redundancy between inspectors and workspaces at this point? How do you think about supporting dynamic bindings in every inspector's evaluator pane via opt-in? Or maybe add an item into Inspector's window menu, "convert to Workspace"?

Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Freitag, 9. Oktober 2020 14:40:43
An: squeak-dev
Betreff: Re: [squeak-dev] assert:equals: in Object

Hi Christoph,

still, it would be a shame if we would remove #assert:(description:) from Object, too. Then we couldn't document invariants in code anymore. So many trade-offs! :-O

As you suggested, this could be better solved at the tool level. The "self" binding in workspaces has great potential. Bind it to an example test case, and this would work. :-)

Best,
Marcel

Am 09.10.2020 14:34:20 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:

Hi Eliot, Hi Marcel,


-1 from my side for this change. :-)


If we start adding #assert:equals: and #assert:equals:description: on Object, it will be only a question of time until we will also discuss #deny:, #should:raise:, and all the other assertion selectors an object. And because it's not every object's purpose to provide such testing mechanisms, this feels like a step in the wrong direction for me. Object is bloated enough already. Instead of defining new assertion selectors (which happens for the single purpose of improving exception messages as I suppose), we should rather inspect the stack of an AssertionFailure/TestFailure to generate precise error messages.


Also, I am against defining these methods as extension methods because I would bet that someone (for example myself) would misinterpret them and assume they are part of the usual Object protocol, and suddenly you have a bunch of new dependencies from production code to SUnit.


Instead, we might miss some proper tooling for your use case, Eliot. Why can't we exchange the class of a Workspace's receiver? Or thinking differently, why can't we support dynamic workspace bindings in every inspector (maybe opt-in)? Then you could just inspect TestCase new, maximize the evaluator pane in the inspector, and e voilá you have a TestCase workspace.


Here are some references that might be related to this issue in some way:

http://forum.world.st/Modifying-a-method-s-bytecodes-is-it-supported-tp5114421p5114435.html (proposal for Workspace variables)

http://forum.world.st/The-Inbox-SUnit-ct-127-mcz-td5114709.html (about the addition of new assertion selectors)


Best,

Christoph

Squeak - Dev - The Inbox: SUnit-ct.127.mcz<http://forum.world.st/The-Inbox-SUnit-ct-127-mcz-td5114709.html>
forum.world.st
The Inbox: SUnit-ct.127.mcz. Christoph Thiede uploaded a new version of SUnit to project The Inbox: http://source.squeak.org/inbox/SUnit-ct.127.mcz ==================== Summary...






________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Freitag, 9. Oktober 2020 11:41:26
An: squeak-dev
Betreff: Re: [squeak-dev] assert:equals: in Object

Hi Eliot,

sure, SUnit could put those extensions into Object. I wouldn't want to have those outside SUnit, though. Not sure why. I only consider #assert: a useful tool even outside test cases. Just to document an invariant in a method.

Best,
Marcel

Am 09.10.2020 10:24:58 schrieb Eliot Miranda <eliot.miranda at gmail.com>:

Hi All,

    moving code from a test into a workspace and back is painful because Object does not implement assert:equals: or assert:equals:description: even though it implements assert:description:.  So one has to edit out the equals: moving to the workspace and edit it back in again on the way back.  I'd like to suggest implementing Object>>assert:equals: and Object>>assert:equals:description: but I won't, because someone is bound to criticise it as being too green or ill considered or some other depressing BS.
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201009/e466daca/attachment.html>


More information about the Squeak-dev mailing list