Hi Marcel,<br>
<br>
for smalltalkCI, SUnit may still depend on other packages, may it not? If SCI is used to test Cuis or anything else, I hope that it will use a Cuis version of SUnit. We only need to provide an agreed cross-dialect protocol for the main test entry points here, right?<br>
<br>
I have the impression that #runCaseAsFailure:/#openDebuggerForFailingMethod would not really fall into this category of entry points, since smalltalkCI is not an interactive system and will not try to debug your cases. :-)<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2022-01-14T10:17:14+01:00, marcel.taeumel@hpi.de wrote:<br>
<br>
> Hi Christoph --<br>
> <br>
> > But the SUnit version in Squeak no longer needs to be dialect-unspecific, does it?<br>
> <br>
> Yes, it does. See the smalltalkCI project. Please don't break this if we can keep it compatible without much effort. Thanks.<br>
> <br>
> Best,<br>
> Marcel<br>
> Am 14.01.2022 00:33:20 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:<br>
> Hi Jakob,<br>
> <br>
> > Good that it stops in a method without the test timeout, which always gives me headaches with the Through button if I try to debug through setUp and tearDown. :-)<br>
> <br>
> Yeah, I know that feeling ... ^^<br>
> By the way, it is also tedious when you click a failing method in a test runner and nothing happens, because the failure was an undebuggable "Heisen timeout". But you get used to this. :D<br>
> <br>
> <br>
> > The original reason for the halt might have been that SUnit works across Smalltalk dialects. http://sunit.sourceforge.net/<br>
> <br>
> But the SUnit version in Squeak no longer needs to be dialect-unspecific, does it? If yes, this really should have been made more clearly and enforced by tests.<br>
> <br>
> > I like the changed experience, but here is one theoretical doubt: what if a project has overrides for #runCase or #runCaseAsFailure: in good faith, or what if they send #runCaseAsFailure: or #debug from a<br>
> specialized test runner (however that would look like with the user interaction)? In #debug they will no longer get their #runCase behavior and #runCaseAsFailure: is now deprecated.<br>
> <br>
> You are right, these are pretty theoretical issues. :-) With our current tooling, it is hard to know. I like to use Sourcegraph for questions like this [https://sourcegraph.com/search?q=context:global&#43;runCaseAsFailure&#43;lang:smalltalk&#43;-lang:c%23&amp;patternType=literal], but it comes with the limitation of a) including projects for alternative Smalltalk distributions and b) not including SqueakSource projects. Anyway, this is what we have the Deprecated package for, isn't it? And of course, we can revise this change if anyone finds the way to squeak-dev because an update broke something in their project. But I guess the probability for this is rather small, don't you? #runCaseAsFailure: never looked like a public protocol to me. PathMap is not being maintained any longer and does not even run of Squeak 5.0.<br>
> <br>
> Best,<br>
> Christoph<br>
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <jakres+squeak at gmail.com><br>
> Gesendet: Donnerstag, 13. Januar 2022 23:32:38<br>
> An: squeak-dev at lists.squeakfoundation.org<br>
> Cc: packages at lists.squeakfoundation.org<br>
> Betreff: Re: [squeak-dev] The Trunk: SUnit-ct.133.mcz<br>
>  <br>
> Good that it stops in a method without the test timeout, which always<br>
> gives me headaches with the Through button if I try to debug through<br>
> setUp and tearDown. :-)<br>
> <br>
> The original reason for the halt might have been that SUnit works<br>
> across Smalltalk dialects. http://sunit.sourceforge.net/ [http://sunit.sourceforge.net/]<br>
> The Squeak facility of jumping into a Process just at the right<br>
> context is not so portable, of course.<br>
> <br>
> I like the changed experience, but here is one theoretical doubt: what<br>
> if a project has overrides for #runCase or #runCaseAsFailure: in good<br>
> faith, or what if they send #runCaseAsFailure: or #debug from a<br>
> specialized test runner (however that would look like with the user<br>
> interaction)? In #debug they will no longer get their #runCase<br>
> behavior and #runCaseAsFailure: is now deprecated.<br>
> <br>
> Am Mo., 10. Jan. 2022 um 19:03 Uhr schrieb <commits at source.squeak.org>:<br>
> ><br>
> > Christoph Thiede uploaded a new version of SUnit to project The Trunk:<br>
> > http://source.squeak.org/trunk/SUnit-ct.133.mcz [http://source.squeak.org/trunk/SUnit-ct.133.mcz]<br>
> ><br>
> > ==================== Summary ====================<br>
> ><br>
> > Name: SUnit-ct.133<br>
> > Author: ct<br>
> > Time: 29 December 2021, 6:38:28.060638 pm<br>
> > UUID: 83af50fb-86e6-d843-8e9e-9abe8e8e379a<br>
> > Ancestors: SUnit-mt.125<br>
> ><br>
> > Updates debugging logic of TestCase. Instead of abusing #halt, open a debugger directly on the entrypoint to run the case. Deprecates #openDebuggerOnFailingTestMethod.<br>
> ><br>
> > Also slightly refactors internal behavior to avoid some duplication, and to get rid of unnecessary semaphores which do not add any value compared to #ensure: unless some really low-level things are broken.<br>
> ><br>
> > Supersedes SUnit-ct.125. Based on my own experiences from >1.5 years, I have revised #debugAsFailure to always halt right before sending #setUp. This improves a) the explorability of any custom set-up/tear-down logic of the test case and b) the immediacy of opening a debugger if you have a very heavy #setUp implementation. From the user perspective, effectively, you still have to click "Over-into-over-into" to navigate into the actual test method.<br>
> ><br>
> > Please report back whether you find this behavior acceptable. :-)<br>
> ><br>
> > =============== Diff against SUnit-mt.125 ===============<br>
> ><br>
> > Item was added:<br>
> > + ----- Method: TestCase>>assureResourcesDuring: (in category 'private') -----<br>
> > + assureResourcesDuring: aBlock<br>
> > +<br>
> > +       | resources |<br>
> > +       resources := self resources.<br>
> > +       resources do: [:resource |<br>
> > +               resource isAvailable ifFalse: [<br>
> > +                       ^ resource signalInitializationError]].<br>
> > +       ^ aBlock ensure: [<br>
> > +               resources do: [:resource |<br>
> > +                       resource reset]].!<br>
> ><br>
> > Item was changed:<br>
> >   ----- Method: TestCase>>debug (in category 'running') -----<br>
> >   debug<br>
> > +       "Run the receiver and open a debugger on the first failure or error."<br>
> > +<br>
> > +       ^ self assureResourcesDuring: [self runCaseWithoutTimeout]!<br>
> > -       self resources do:<br>
> > -               [ : res | res isAvailable ifFalse: [ ^ res signalInitializationError ] ].<br>
> > -       [ self runCase ] ensure:<br>
> > -               [ self resources do:<br>
> > -                       [ : each | each reset ] ]!<br>
> ><br>
> > Item was changed:<br>
> >   ----- Method: TestCase>>debugAsFailure (in category 'running') -----<br>
> >   debugAsFailure<br>
> > +       "Spawn a debugger that is ready to debug the receiver."<br>
> > +<br>
> > +       (Process<br>
> > +               forBlock: [self debug]<br>
> > +               runUntil: [:context | context isClosureContext "navigate the process directly to the point where it is about to send #setUp"<br>
> > +                       and: [context selector = #runCaseWithoutTimeout]])<br>
> > +                               debug.!<br>
> > -       | semaphore |<br>
> > -       semaphore := Semaphore new.<br>
> > -       self resources do: [:res |<br>
> > -               res isAvailable ifFalse: [^res signalInitializationError]].<br>
> > -       [semaphore wait. self resources do: [:each | each reset]] fork.<br>
> > -       (self class selector: testSelector) runCaseAsFailure: semaphore.!<br>
> ><br>
> > Item was changed:<br>
> >   ----- Method: TestCase>>openDebuggerOnFailingTestMethod (in category 'running') -----<br>
> >   openDebuggerOnFailingTestMethod<br>
> > +<br>
> > +       self deprecated: 'ct: Use #debugAsFailure'.<br>
> > +<br>
> >         "SUnit has halted one step in front of the failing test method. Step over the 'self halt' and<br>
> >          send into 'self perform: testSelector' to see the failure from the beginning"<br>
> > -<br>
> >         self<br>
> >                 halt;<br>
> >                 performTest!<br>
> ><br>
> > Item was changed:<br>
> >   ----- Method: TestCase>>runCaseAsFailure: (in category 'running') -----<br>
> >   runCaseAsFailure: aSemaphore<br>
> > +<br>
> > +       self deprecated: 'ct: Use #runCaseWithoutTimeout and #ensure:'.<br>
> > +       ^ [self runCaseWithoutTimeout]<br>
> > +               ensure: [aSemaphore signal]!<br>
> > -       [self setUp.<br>
> > -       self openDebuggerOnFailingTestMethod] ensure: [<br>
> > -               self tearDown.<br>
> > -               aSemaphore signal]!<br>
> ><br>
> > Item was added:<br>
> > + ----- Method: TestCase>>runCaseWithoutTimeout (in category 'running') -----<br>
> > + runCaseWithoutTimeout<br>
> > +<br>
> > +       [self setUp.<br>
> > +       self performTest]<br>
> > +               ensure: [self tearDown].!<br>
> ><br>
> ><br>
> <br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/2329871c/attachment.html><br>
> <br>