[squeak-dev] The Trunk: MorphicTests-nice.75.mcz

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat May 1 16:52:08 UTC 2021


Hi Marcel,


> The use of "Preferences" would add a dependency to System, for example.


<http://www.hpi.de/>
I think this is bearable because Preferences is indeed a manager for preferences of all kinds. Also, from a practical perspective, I doubt that we will be ever able to unload System from a Squeak image. :-)

> In this case, a "during:" mechanism would not work because #setUp and #tearDown are called by the SUnit "framework" :-) Maybe SUnit could provide some configurable way for this.

Yeah, that's a common problem ... I could imagine two possible solutions for this problem:


  1.  Override #performTest and wrap it with all your executeAround-logic. I do this quite often, but it does not really feel elegant to me ...
  2.  We could add something like #wrap: to the TestCase interface. Example:

setUp

    super setUp.

    self wrap: [:block | Preferences restoreAfter: block].
    Model useColorfulWindows: true.
    ...

See also Context >> #wrap: here: https://github.com/LinqLover/SimulationStudio/blob/5a0ddad75130e947a270bc6dd0ab7e3b0aa4e562/packages/SimulationStudio-Base.package/Context.extension/instance/wrap..st

What do you think, can I send something like this to the inbox? :-)

> In System-ct.1119, I do not like the overuse of symbols and meta-programming in client code (e.g. a test's #setUp). In preferences, the entire construction of a key for pragma preferences feels like an ugly hack.

Agreed. :-) At least these symbols are a private implementation detail of Preferences.

> SUnit could just snapshot all their values before the test and reset them after.

Interesting approach. :-) But I think we could only do this if all preferences were consistently implemented with dynamic scoping - it would be too confusing if you edited your preferences while a test debugger remains opened in your image, and after closing the debugger, your changes to these preferences were lost. This, again, would require a stronger framework for managing preferences (one that does not delegate the control of their values to the defining classes), so in the end, I guess this is not feasible for us without major breaking changes ...

Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 26. April 2021 18:36:35
An: squeak-dev
Betreff: Re: [squeak-dev] The Trunk: MorphicTests-nice.75.mcz

Hi Christoph.

> we already have #setPreference:toValue:during: on Preferences class

Hmm... I think that I am reluctant to use the "Preferences" interface for pragma preferences, which have the benefit of directly showing the domain they are used for. The use of "Preferences" would add a dependency to System, for example.

In this case, a "during:" mechanism would not work because #setUp and #tearDown are called by the SUnit "framework" :-) Maybe SUnit could provide some configurable way for this.

In System-ct.1119, I do not like the overuse of symbols and meta-programming in client code (e.g. a test's #setUp). In preferences, the entire construction of a key for pragma preferences feels like an ugly hack.

Hmm... actually, pragma preferences and other Preferences are easily accessible. SUnit could just snapshot all their values before the test and reset them after. The values are mostly primitive, immutable objects. An extra reference to them would suffice. A test's #setUp code could do what it wants to do and then rely on the implicit reset of all preferences in #tearDown. Hmm....

Best,
Marcel


Am 25.04.2021 20:23:27 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:

Hi Marcel,


we already have #setPreference:toValue:during: on Preferences class. I also had to remember this proposal + discussion: The Inbox: System-ct.1119.mcz<http://forum.world.st/The-Inbox-System-ct-1119-mcz-td5106025.html> Your counter-proposal with the preferences sandbox also sounds interesting, we could do this as well.


(Just now, I am wondering whether preferences should be process-local ... But that's enough stuff for its own discussion. :-))


Best,

Christoph

<http://www.hpi.de/>
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Donnerstag, 15. April 2021 09:39:57
An: squeak-dev
Betreff: Re: [squeak-dev] The Trunk: MorphicTests-nice.75.mcz

Hi Nicolas.

Thanks. We might want to think about a more generic way to specify system-wide preferences for tests. Maybe a new feature in TestCase (or SUnit). While I would never want to change such preferences in a specific test, I also see that the setUp-way (with that extra "reset" instVar) is quite cumbersome.

Best,
Marcel

Am 14.04.2021 19:14:23 schrieb commits at source.squeak.org <commits at source.squeak.org>:

Nicolas Cellier uploaded a new version of MorphicTests to project The Trunk:
http://source.squeak.org/trunk/MorphicTests-nice.75.mcz

==================== Summary ====================

Name: MorphicTests-nice.75
Author: nice
Time: 14 April 2021, 7:14:06.997889 pm
UUID: d87c50dd-4e44-5242-9120-37e0452ca781
Ancestors: MorphicTests-eem.74

Fix loss of useRetractableScrollBars preference

=============== Diff against MorphicTests-eem.74 ===============

Item was changed:
----- Method: TableLayoutTest>>setUp (in category 'running') -----
setUp

super setUp.
-
reset := {
([:enable | [self useRetractableScrollBars: enable]]
value: self useRetractableScrollBars)
+ }.
+ self useRetractableScrollBars: false!
- in: [:block | self useRetractableScrollBars: false].
- }.!


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


More information about the Squeak-dev mailing list