Given some possible inconveniences with the TestRunner, I am moving this to the treated inbox for now.

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2019-08-14T19:14:56+00:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:

> > What are the specific information in the test runner you are referring to?
> 
> It is "reentrant", you do not need to re-run all tests after debugging one. A DialogBox would need to be manually set as non-exclusive.
> 
> 
> > If the test runner would be a better option than the dialog, wouldn't we want to show it even if only a single test fails (result defects size = 1)?
> 
> You're right, we could :)
> 
> 
> 
> Basically, I proposed these change because I did not really found a DialogBox comfortable for this purpose.
> 
> It is modally exclusive but not reentrant.
> 
> (I believe long test selector were displayed abbreviated, but I can't reproduce that.)
> 
> Also, DialogBoxes are not resizable.
> 
> 
> 
> On the other hand, I actually avoided using TestRunner in the last time, as it has a few convenience drawbacks:
> 
> 1. I repeatedly faced an issue where a test, after debugging it, was not tear-downed correctly. Will try to reproduce that.
> 
> 2. You cannot select a test without running it (impractical if you would like to open the menu, for example to browse it). Vice versa, you cannot run a test without selecting it, so the keyboard handling (such as navigation using arrow keys) is quite restricted ...
> 
> 3. TestRunner is not aware of any additions to the test list (maybe we need something like #didCodeChangeElsewhere)
> 
> 
> But your words "specific information" sound interesting to me. Would it be an option to turn the TestRunner upside down, aiming to display the last error information for each test?
> 
> Some wild ideas :-)
> 
>   *   allow selection of single test cases; instead of separately displaying all errors/failures, display their success with an icon
>   *   add another panel to display information for the selected test
>      *   this might include the failing line of the test method, the full error message (displayed in a big TextMorph, not as a one-liner with insufficient space), maybe the context stack - basically something like a collapsed debugger view
>      *   I had an idea in the back of my mind for a few months: One could set up a small extension-based framework that provides additional information about the failing assertion (if you're interested, I can tell you more) - we could display these information here
>         *   for example, in [self assert: [string allSatisfy: #isDigit]], instead of "AssertionFailed", the failure description could be something like "expected all elements of <'123a5'> to satisfy <#isDigit>, but <'a'> at index <4> didn't"
>         *   ideally, the information would not be restricted to textual representation (why not import a diff view or an Inspector into the TestRunner? :) )
>      *   It would be also possible to display *all* failures, not only the first one (I once read about resumable TestFailure implementations, why is TestFailure not marked as resumable by default?)
>   *   If there are only few tests, maybe the test runner could suspend the failing/erroneous ones (actually their threads) instead of shutting them down? The user could then resume a test and directly jump to the raised Exception in debugger, without needing to wait for the test to re-run. Especially in case of heavy tests this might be a great help to some users.
>   *   By always displaying the source of the selected test method, we could improve the overall liveness of SUnit
> 
> It's not a bunch, it's a forest of ideas, I know :) What do you think about them? Or are you already happy with the current TestRunner?
> 
> Best,
> Christoph
> 
> ________________________________
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
> Gesendet: Mittwoch, 14. August 2019 17:03 Uhr
> An: John Pfersich via Squeak-dev
> Betreff: Re: [squeak-dev] The Inbox: SUnitTools-ct.5.mcz
> 
> Hmmm.... What are the specific information in the test runner you are referring to? If the test runner would be a better option than the dialog, wouldn't we want to show it even if only a single test fails (result defects size = 1)?
> 
> Best,
> Marcel
> 
> Am 31.05.2019 14:15:43 schrieb commits at source.squeak.org <commits at source.squeak.org>:
> 
> A new version of SUnitTools was added to project The Inbox:
> http://source.squeak.org/inbox/SUnitTools-ct.5.mcz
> 
> ==================== Summary ====================
> 
> Name: SUnitTools-ct.5
> Author: ct
> Time: 31 May 2019, 2:15:36.714053 pm
> UUID: 397d3b85-7ac5-3645-baa9-b9f848d90880
> Ancestors: SUnitTools-tcj.4
> 
> Change CodeHolder>>testRunSuite: -- if multiple tests fail, instead of a UIManager dialog, open a TestRunner window that provides specific information.
> 
> Depends on SUnitGUI-ct.70.
> 
> =============== Diff against SUnitTools-tcj.4 ===============
> 
> Item was changed:
> ----- Method: CodeHolder>>testRunSuite: (in category '*SUnitTools-running') -----
> testRunSuite: suite
> 
> + | runner result |
> + (suite isKindOf: TestCase)
> + ifFalse: [
> + runner := TestRunner newForSuite: suite.
> + result := runner runAll; result]
> + ifTrue: [result := suite run].
> - | result |
> - result := suite run.
> 
> (result respondsTo: #dispatchResultsIntoHistory)
> ifTrue: [result dispatchResultsIntoHistory].
> 
> result hasPassed ifTrue: [^ self].
> 
> + result defects size = 1
> + ifTrue: [result defects anyOne debug]
> + ifFalse: [runner open]!
> - (result defects size = 1
> - ifTrue: [result defects anyOne]
> - ifFalse: [UIManager default
> - chooseFrom: (result defects collect: [:each | each class name , '>>' , each selector printString])
> - values: result defects
> - title: ('{1} passes, {2} failures, {3} errors\\Debug a failure or error?' format: {
> - result runCount . result failureCount . result errorCount}) withCRs]
> - ) ifNotNil: [:defect | defect debug].
> - !
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190814/3e576b10/attachment.html>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220110/71c0b9aa/attachment.html>