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
On 15 Sep 2016, at 18:38, Ben Coman <btc@openinworld.com> wrote:
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: [ .... ]
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
2016-09-15 18:46 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
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?
It could be used here but I think such problem is more complex. Most parts of system is not implemented with concurrency in mind.
I think it would be nice to be able to run tests in background. What would be the problem? A test case that fails because you were doing something at the same time? I think it is not so serious, it is up to you to know which tests did you run and do nothing that would conflict with the test run. Now you can't do anything. On Fri, Sep 16, 2016 at 11:30 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-09-15 18:46 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
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?
It could be used here but I think such problem is more complex. Most parts of system is not implemented with concurrency in mind.
On 16 Sep 2016, at 12:43, Nicolas Passerini <npasserini@gmail.com> 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 <marcus.denker@inria.fr> wrote:
On 16 Sep 2016, at 12:43, Nicolas Passerini <npasserini@gmail.com> 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.
-------- Original Message --------
On Fri, Sep 16, 2016 at 12:47 PM, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
> On 16 Sep 2016, at 12:43, Nicolas Passerini <npasserini@gmail.com <mailto:npasserini@gmail.com>> 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. On Fri, Sep 16, 2016 at 4:13 PM, Guille Polito <guillermopolito@gmail.com> wrote:
-------- Original Message --------
On Fri, Sep 16, 2016 at 12:47 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 16 Sep 2016, at 12:43, Nicolas Passerini <npasserini@gmail.com> 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
2016-09-16 12:43 GMT+02:00 Nicolas Passerini <npasserini@gmail.com>:
I think it would be nice to be able to run tests in background.
What would be the problem? A test case that fails because you were doing something at the same time? I think it is not so serious, it is up to you to know which tests did you run and do nothing that would conflict with the test run. Now you can't do anything.
I also want to load code in background.
Hi. 2016-09-15 18:38 GMT+02:00 Ben Coman <btc@openinworld.com>:
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: [ .... ]
Now with introduction of ExecutionEnvironment we could delegate this behaviour to it. So DefaultExecutionEnvironment will perform regular UI request but TestExecutionEnvironment will set up special "TestRunner name". We could define CurrentExecutionEnvironment>>systemUser to hide this logic
participants (6)
-
Ben Coman -
Denis Kudriashov -
Guille Polito -
Marcus Denker -
Nicolas Passerini -
stepharo