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]. - }.! |
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
|
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 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 Von: Squeak-dev <[hidden email]> 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
Carpe Squeak!
|
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
|
Hi Marcel,
> The use of "Preferences" would add a dependency to System, for example. 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:
> 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 <[hidden email]> 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
Carpe Squeak!
|
Free forum by Nabble | Edit this page |