[squeak-dev] The Inbox: SUnitGUI-ct.85.mcz

Marcel Taeumel marcel.taeumel at hpi.de
Fri Jan 28 07:31:03 UTC 2022


Hi Christoph --

> Could we maybe just define a "special list" for these components/packages?

No, we don't have a list of third-party projects that rely on this behavior. In order to improve this, you should offer a different way of coverage collection, not modifying the existing one.

Best,
Marcel
Am 27.01.2022 18:19:20 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi Marcel,

I think that this argument only applies to very few classes that are run on a higher priority than normal (for instance, the low space watcher). Could we maybe just define a "special list" for these components/packages? Or alternatively, ask the user whether to run on the highest priority or not? Or similarly to #ignoreForCoverage/#classNamesNotUnderTest/#packageNamesUnderTest, allow the source code under test to specify #deniesInterruptabilityForCoverage per method or per class? Then we could specify this attribute for WeakArray and Semaphore, for instance.

I understand that we do not want to break code coverage for all Trunk packages, but this only affects a small minority of use cases for this tool whereas not being able to interrupt the test runner affects every developer for every third-party package.

Best,
Christoph
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 24. Januar 2022 08:31:23
An: squeak-dev
Betreff: Re: [squeak-dev] The Inbox: SUnitGUI-ct.85.mcz
 
Hi Christoph --

-1

#valueUnpreemptively is the only mechanism we have at this point to collect somewhat reliable coverage statistics. If you have a better idea, okay. But let's not break this existing facility here. It would modify the statistics being collected.

Best,
Marcel
Am 23.01.2022 16:44:54 schrieb commits at source.squeak.org <commits at source.squeak.org>:
A new version of SUnitGUI was added to project The Inbox:
http://source.squeak.org/inbox/SUnitGUI-ct.85.mcz

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

Name: SUnitGUI-ct.85
Author: ct
Time: 23 January 2022, 4:44:44.095219 pm
UUID: c523a4d5-d9aa-7347-8e2f-66452a540c30
Ancestors: SUnitGUI-ct.84

Proposal: Do not use #valueUnpreemptively for collecting coverage in the TestRunner. The former behavior made it impossible to interrupt a hanging test and also led to errors in all tests that try to schedule a process on a priority above the active priority.

I have been happily using this setting for a few months in multiple images. The downside is that any processes running with higher-than-normal priority could interfere the results, but this only applies to code in the Kernel packages which is often not OaM-safe anyway.

=============== Diff against SUnitGUI-ct.84 ===============

Item was changed:
----- Method: TestRunner>>collectCoverageFor: (in category 'actions') -----
collectCoverageFor: methods
| wrappers suite |
wrappers := methods collect: [ :each | TestCoverage on: each ].
suite := self
reset;
suiteAll.

+ wrappers do: [ :each | each install ].
+ [ self runSuite: suite ] ensure: [ wrappers do: [ :each | each uninstall ] ].
- [ wrappers do: [ :each | each install ].
- [ self runSuite: suite ] ensure: [ wrappers do: [ :each | each uninstall ] ] ] valueUnpreemptively.
wrappers := wrappers reject: [ :each | each hasRun ].
wrappers isEmpty
ifTrue:
+ [ self inform: 'Congratulations. Your tests cover all code under analysis.' translated ]
- [ UIManager default inform: 'Congratulations. Your tests cover all code under analysis.' ]
ifFalse:
[ ToolSet
browseMessageSet: (wrappers collect: [ :each | each reference ])
+ name: ('Not Covered Code ({1}% Code Coverage)' translated format: {100 - (100 * wrappers size // methods size)})
- name: 'Not Covered Code (' , (100 - (100 * wrappers size // methods size)) printString , '% Code Coverage)'
autoSelect: nil ].
self saveResultInHistory!


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


More information about the Squeak-dev mailing list