Author / TestRunner interaction in fresh image

In a freshly downloaded build 60224, I open TestRunner and run all
tests.  At run 418 I get a dialogue asking for the Author.  To me that
seems wrong.  I don't want any code changes made during testing to
have my normal identification on them. Tests invoked from Test Runner
should be author-tagged something like 'TestRunner' or
'TestRunner-BenComan'.

The question arises in this particular case due to...
  RPackageMonticelloSynchronisationTest >> setUp
      ...
      Author fullName ifNil: [ Author fullName: 'Tester' ].

Minor point... this check actually is a bit pointless since #fullName
invokes #requestFullName that presents the dialog.  And #fullName will
*never* return nil. At a minimum it returns 'Anonymous'.

First step would seem to be wrapping  TestCase>>runCase:
with   Author useAuthor: 'TestRunner' during: [ .... ]

But further. I envisage a time when TestRunner doesn't block the UI,
so I can happily browse around the system and code while TestRunner is
doing its thing.  Obviously the system is not set up to have two
parties (myself and TestRunner) both updating code in the system, but
changing the state of the global Author uniqueInstance like this...

   Author>>useAuthor: aString during: aBlock
          ^ self uniqueInstance useAuthor: aString during: aBlock

would itself seem to a big impediment.   It would be good if "Author"
was dependent on the context of the call chain.    This would seem a
requirement for one day having two people working in the one Image (is
this a possible use case where someone is using a remote debugger
while another person is using the standard UI?)

So my second proposal is for Author>>fullName to invoke a Notification
mechanism to determine #fullName.  Something like...

     Notification subclass: AuthorRequest

     Author>>#fullName
           ^ AuthorRequest new signal
                   instanceVariables: 'contextFullName'.

    Author>>useAuthor: tempAuthorFullname during: aBlock
          [ block ]
             on: AuthorRequest
             do: [ :noti | noti contextFullName: tempAuthorFullname ]

with only unhandled AuthorRequests returning "Author uniqueInstance
basicFullname".

Thus code changes are not constrained to be assigned to a global
author.  Not that we *yet* have multiple people working in one image,
but one more impediment is removed - step by step.

What concerns would there be?

cheers -ben

Yes, something like this this would be good.

> But further. I envisage a time when TestRunner doesn't block the UI,
> so I can happily browse around the system and code while TestRunner is
> doing its thing.  Obviously the system is not set up to have two
> parties (myself and TestRunner) both updating code in the system, but
> changing the state of the global Author uniqueInstance like this…
>

Yes, Nautilus used to fork running tests… leads to lots of strange problems.

>
> would itself seem to a big impediment.   It would be good if "Author"
> was dependent on the context of the call chain.    This would seem a
> requirement for one day having two people working in the one Image (is
> this a possible use case where someone is using a remote debugger
> while another person is using the standard UI?)
>
Could it be part of Denis new ExecutionEnvironment concept?

        Marcus

> On 16 Sep 2016, at 12:43, Nicolas Passerini <[hidden email]> wrote:
>
> I think it would be nice to be able to run tests in background.
>

The easiest is to start multiple images… this way they can destroy whatever without impacting you.
I think Guille has something in preparation…

The nice aspect of this is that it runs really in parallel.

        Marcus

On Fri, Sep 16, 2016 at 12:47 PM, Marcus Denker <[hidden email]> wrote:

> On 16 Sep 2016, at 12:43, Nicolas Passerini <[hidden email]> wrote:
>
> I think it would be nice to be able to run tests in background.
>

The easiest is to start multiple images… this way they can destroy whatever without impacting you.
I think Guille has something in preparation…

The nice aspect of this is that it runs really in parallel.

 That is a nice feature, but if I am working on something and I make changes I would like to run the tests right where I am working.

That is a cosmethic thing.

Imagine you could run the tests on a copy of the image you were developing. If there is an error, your development image gets notified, and so you can then debug the error on your local environment.

> Yes, that would be great.
>
> I just wander if the increased complexity pays off... normally if I am
> running my tests I do not have lots of tasks in mind, I will decide
> what to do next after seeing that my tests are green. Maybe I just
> want to browse some code, I do not need super fancy features.

Nico the problems are not your tests but the tests somebody else wrote
and that may destroy the package integrity or think like that.

Stef