Rubric test failures

> Thanks. I got the same problem and I do not know where to start from. It's really strange.
>
> For those interested, the tests are in the GLMRubricTextMorphicTest class. If you run all of them repeatedly, you get some errors. If you run them individually, you do not.
>
> Alain: do you happen to have an insight?
>
> Doru
>
>
> On Tue, Jul 2, 2013 at 11:53 AM, Yuriy Tymchuk <[hidden email]> wrote:
> Hi guys.
>
> I hope that we can release 4.8 and move to Pharo 3.0 soon. I wanted to fix failing tests and the only one is Rubric test. I was working with it for some time, and I have no idea what's up. When you run tests separately they work fine, but when being run in a suite some test fail and failures are inflicted by test order
>
> Maybe someone have ideas where to look at? UI maybe?
>
> Uko
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"

> Thanks. I got the same problem and I do not know where to start from. It's really strange.
>
> For those interested, the tests are in the GLMRubricTextMorphicTest class. If you run all of them repeatedly, you get some errors. If you run them individually, you do not.
>
> Alain: do you happen to have an insight?
>
> Doru
>
>
> On Tue, Jul 2, 2013 at 11:53 AM, Yuriy Tymchuk <[hidden email]> wrote:
> Hi guys.
>
> I hope that we can release 4.8 and move to Pharo 3.0 soon. I wanted to fix failing tests and the only one is Rubric test. I was working with it for some time, and I have no idea what's up. When you run tests separately they work fine, but when being run in a suite some test fail and failures are inflicted by test order
>
> Maybe someone have ideas where to look at? UI maybe?
>
> Uko
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"

> Thanks. I got the same problem and I do not know where to start from. It's really strange.
>
> For those interested, the tests are in the GLMRubricTextMorphicTest class. If you run all of them repeatedly, you get some errors. If you run them individually, you do not.
>
> Alain: do you happen to have an insight?
>
> Doru
>
>
> On Tue, Jul 2, 2013 at 11:53 AM, Yuriy Tymchuk <[hidden email]> wrote:
> Hi guys.
>
> I hope that we can release 4.8 and move to Pharo 3.0 soon. I wanted to fix failing tests and the only one is Rubric test. I was working with it for some time, and I have no idea what's up. When you run tests separately they work fine, but when being run in a suite some test fail and failures are inflicted by test order
>
> Maybe someone have ideas where to look at? UI maybe?
>
> Uko
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"

> and if one add a #inspect send in a testMethod, the results are the same with the TestRunner but differ
> if one run them from Nautilus.
> As an example, with:
> -----
> testEnteringTextInPort
> | composite textMorph |
> composite := GLMCompositePresentation new with: [ :a | a rubricText display: '' ].
> window := composite openOn: 4.
> textMorph := self find: RubScrolledTextMorph in: window.
> textMorph simulateClick.
> self assert: textMorph activeHand keyboardFocus = textMorph textArea.
> self simulateKeyStrokes: 'hello'.
> (composite pane port: #text) value asString inspect.  <-------------------------------- ** inspect added here **
> self assert: (composite pane port: #text) value asString = 'hello'
> ----
> by running tests from Nautilus, the inspect runs ok and the result string is 'hello'.
> but now #testAcceptKeyCanBeOverriden turns yellow
>
> by running test from the TestRunner, #testEnteringTextInPort and #testPastingUpdatesTextPort stay yellow (as without the inspect)
> and #testAcceptKeyCanBeOverriden is green
>
> Alain
>
>
> Le 2 juil. 2013 à 12:49, Tudor Girba <[hidden email]> a écrit :
>
>> Thanks. I got the same problem and I do not know where to start from. It's really strange.
>>
>> For those interested, the tests are in the GLMRubricTextMorphicTest class. If you run all of them repeatedly, you get some errors. If you run them individually, you do not.
>>
>> Alain: do you happen to have an insight?
>>
>> Doru
>>
>>
>> On Tue, Jul 2, 2013 at 11:53 AM, Yuriy Tymchuk <[hidden email]> wrote:
>> Hi guys.
>>
>> I hope that we can release 4.8 and move to Pharo 3.0 soon. I wanted to fix failing tests and the only one is Rubric test. I was working with it for some time, and I have no idea what's up. When you run tests separately they work fine, but when being run in a suite some test fail and failures are inflicted by test order
>>
>> Maybe someone have ideas where to look at? UI maybe?
>>
>> Uko
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>
>

> ok, I 've a track
> With rubric, if a textArea do not have the focus but has a selection, then the first click on it give it the focus but don't deselect.
> In that case, one have to click to times to have the old TextMorph behavior.
> So, depending on the goal of the test, one have to send simulateClick one time or two times and not alway only one time.
> I will dig more to really understand.
>
>
> Le 13 juil. 2013 à 10:11, Alain Plantec <[hidden email]> a écrit :
>
>> and if one add a #inspect send in a testMethod, the results are the same with the TestRunner but differ
>> if one run them from Nautilus.
>> As an example, with:
>> -----
>> testEnteringTextInPort
>> | composite textMorph |
>> composite := GLMCompositePresentation new with: [ :a | a rubricText display: '' ].
>> window := composite openOn: 4.
>> textMorph := self find: RubScrolledTextMorph in: window.
>> textMorph simulateClick.
>> self assert: textMorph activeHand keyboardFocus = textMorph textArea.
>> self simulateKeyStrokes: 'hello'.
>> (composite pane port: #text) value asString inspect.  <-------------------------------- ** inspect added here **
>> self assert: (composite pane port: #text) value asString = 'hello'
>> ----
>> by running tests from Nautilus, the inspect runs ok and the result string is 'hello'.
>> but now #testAcceptKeyCanBeOverriden turns yellow
>>
>> by running test from the TestRunner, #testEnteringTextInPort and #testPastingUpdatesTextPort stay yellow (as without the inspect)
>> and #testAcceptKeyCanBeOverriden is green
>>
>> Alain
>>
>>
>> Le 2 juil. 2013 à 12:49, Tudor Girba <[hidden email]> a écrit :
>>
>>> Thanks. I got the same problem and I do not know where to start from. It's really strange.
>>>
>>> For those interested, the tests are in the GLMRubricTextMorphicTest class. If you run all of them repeatedly, you get some errors. If you run them individually, you do not.
>>>
>>> Alain: do you happen to have an insight?
>>>
>>> Doru
>>>
>>>
>>> On Tue, Jul 2, 2013 at 11:53 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>> Hi guys.
>>>
>>> I hope that we can release 4.8 and move to Pharo 3.0 soon. I wanted to fix failing tests and the only one is Rubric test. I was working with it for some time, and I have no idea what's up. When you run tests separately they work fine, but when being run in a suite some test fail and failures are inflicted by test order
>>>
>>> Maybe someone have ideas where to look at? UI maybe?
>>>
>>> Uko
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>
>>
>

> Wow, thank you very much for looking into this.
>
> Doru
>
>
> On Jul 13, 2013, at 3:14 PM, Alain Plantec <[hidden email]> wrote:
>
>> ok, I 've a track
>> With rubric, if a textArea do not have the focus but has a selection, then the first click on it give it the focus but don't deselect.
>> In that case, one have to click to times to have the old TextMorph behavior.
>> So, depending on the goal of the test, one have to send simulateClick one time or two times and not alway only one time.
>> I will dig more to really understand.
>>
>>
>> Le 13 juil. 2013 à 10:11, Alain Plantec <[hidden email]> a écrit :
>>
>>> and if one add a #inspect send in a testMethod, the results are the same with the TestRunner but differ
>>> if one run them from Nautilus.
>>> As an example, with:
>>> -----
>>> testEnteringTextInPort
>>> | composite textMorph |
>>> composite := GLMCompositePresentation new with: [ :a | a rubricText display: '' ].
>>> window := composite openOn: 4.
>>> textMorph := self find: RubScrolledTextMorph in: window.
>>> textMorph simulateClick.
>>> self assert: textMorph activeHand keyboardFocus = textMorph textArea.
>>> self simulateKeyStrokes: 'hello'.
>>> (composite pane port: #text) value asString inspect.  <-------------------------------- ** inspect added here **
>>> self assert: (composite pane port: #text) value asString = 'hello'
>>> ----
>>> by running tests from Nautilus, the inspect runs ok and the result string is 'hello'.
>>> but now #testAcceptKeyCanBeOverriden turns yellow
>>>
>>> by running test from the TestRunner, #testEnteringTextInPort and #testPastingUpdatesTextPort stay yellow (as without the inspect)
>>> and #testAcceptKeyCanBeOverriden is green
>>>
>>> Alain
>>>
>>>
>>> Le 2 juil. 2013 à 12:49, Tudor Girba <[hidden email]> a écrit :
>>>
>>>> Thanks. I got the same problem and I do not know where to start from. It's really strange.
>>>>
>>>> For those interested, the tests are in the GLMRubricTextMorphicTest class. If you run all of them repeatedly, you get some errors. If you run them individually, you do not.
>>>>
>>>> Alain: do you happen to have an insight?
>>>>
>>>> Doru
>>>>
>>>>
>>>> On Tue, Jul 2, 2013 at 11:53 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>>> Hi guys.
>>>>
>>>> I hope that we can release 4.8 and move to Pharo 3.0 soon. I wanted to fix failing tests and the only one is Rubric test. I was working with it for some time, and I have no idea what's up. When you run tests separately they work fine, but when being run in a suite some test fail and failures are inflicted by test order
>>>>
>>>> Maybe someone have ideas where to look at? UI maybe?
>>>>
>>>> Uko
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Every thing has its own flow"
>>>
>>>
>>
>
> --
> www.tudorgirba.com
>
> "If you interrupt the barber while he is cutting your hair,
> you will end up with a messy haircut."
>
>

> yep, caught.
> and finally it is funny :)
>
> It has something to do with #simulateClick.
> In Rubric, MouseClickState is used to have a real doubleClick (whereas in TextMorph, the editor handle click/doubleClick by itself and not with MouseClickState).
> Mouse clickState mesures the time between two MouseDown and decide for a simple click if the time is > than HandMorph doubleClickTime.
> When several tests with simulateClick are runned, then depending on the state of the hand MouseClickState, a simple click or a double click are triggered.
> So it explains why when you run several tests some of then are failing.
> But when you run a single test with a single simultateClick, then it doesn't fail.
>
> the lesson is that mouseClickState should not be shared (instance var of the HandMorph).
> or it should test the target morph and not only the time.
>
>
> the workarround is to wait before any simulateClick, I've tried and it works.
> change the simulateClick method as follow and all your Rubric related tests should be green again.
> --------
> simulateClick
> (Delay forMilliseconds: HandMorph doubleClickTime + 1) wait.
> self simulateClickWith: MouseEvent redButton.
> --------
>
> Cheers
> Alain
>
>
> Le 13 juil. 2013 à 17:26, Tudor Girba <[hidden email]> a écrit :
>
>> Wow, thank you very much for looking into this.
>>
>> Doru
>>
>>
>> On Jul 13, 2013, at 3:14 PM, Alain Plantec <[hidden email]> wrote:
>>
>>> ok, I 've a track
>>> With rubric, if a textArea do not have the focus but has a selection, then the first click on it give it the focus but don't deselect.
>>> In that case, one have to click to times to have the old TextMorph behavior.
>>> So, depending on the goal of the test, one have to send simulateClick one time or two times and not alway only one time.
>>> I will dig more to really understand.
>>>
>>>
>>> Le 13 juil. 2013 à 10:11, Alain Plantec <[hidden email]> a écrit :
>>>
>>>> and if one add a #inspect send in a testMethod, the results are the same with the TestRunner but differ
>>>> if one run them from Nautilus.
>>>> As an example, with:
>>>> -----
>>>> testEnteringTextInPort
>>>> | composite textMorph |
>>>> composite := GLMCompositePresentation new with: [ :a | a rubricText display: '' ].
>>>> window := composite openOn: 4.
>>>> textMorph := self find: RubScrolledTextMorph in: window.
>>>> textMorph simulateClick.
>>>> self assert: textMorph activeHand keyboardFocus = textMorph textArea.
>>>> self simulateKeyStrokes: 'hello'.
>>>> (composite pane port: #text) value asString inspect.  <-------------------------------- ** inspect added here **
>>>> self assert: (composite pane port: #text) value asString = 'hello'
>>>> ----
>>>> by running tests from Nautilus, the inspect runs ok and the result string is 'hello'.
>>>> but now #testAcceptKeyCanBeOverriden turns yellow
>>>>
>>>> by running test from the TestRunner, #testEnteringTextInPort and #testPastingUpdatesTextPort stay yellow (as without the inspect)
>>>> and #testAcceptKeyCanBeOverriden is green
>>>>
>>>> Alain
>>>>
>>>>
>>>> Le 2 juil. 2013 à 12:49, Tudor Girba <[hidden email]> a écrit :
>>>>
>>>>> Thanks. I got the same problem and I do not know where to start from. It's really strange.
>>>>>
>>>>> For those interested, the tests are in the GLMRubricTextMorphicTest class. If you run all of them repeatedly, you get some errors. If you run them individually, you do not.
>>>>>
>>>>> Alain: do you happen to have an insight?
>>>>>
>>>>> Doru
>>>>>
>>>>>
>>>>> On Tue, Jul 2, 2013 at 11:53 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>>>> Hi guys.
>>>>>
>>>>> I hope that we can release 4.8 and move to Pharo 3.0 soon. I wanted to fix failing tests and the only one is Rubric test. I was working with it for some time, and I have no idea what's up. When you run tests separately they work fine, but when being run in a suite some test fail and failures are inflicted by test order
>>>>>
>>>>> Maybe someone have ideas where to look at? UI maybe?
>>>>>
>>>>> Uko
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "Every thing has its own flow"
>>>>
>>>>
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "If you interrupt the barber while he is cutting your hair,
>> you will end up with a messy haircut."
>>
>>
>
>

> This sounds good. I would call the block method as ignoreMultipleClicksWhile:.
>
> Doru
>
>
> On Mon, Jul 15, 2013 at 8:43 AM, Alain Plantec <[hidden email]> wrote:
> maybe another solution would be to unplug the hand mouseclickstate before sending the event and to replug it after.
> something like:
>
> --------
> simulateClick
>         self activeHand forbidMultipleClickWhile: [
>                 self simulateClickWith: MouseEvent redButton]
> --------
> it would be much more efficient.
> I will make a try.
> Alain
>
>
> Le 14 juil. 2013 à 21:26, Alain Plantec <[hidden email]> a écrit :
>
> > yep, caught.
> > and finally it is funny :)
> >
> > It has something to do with #simulateClick.
> > In Rubric, MouseClickState is used to have a real doubleClick (whereas in TextMorph, the editor handle click/doubleClick by itself and not with MouseClickState).
> > Mouse clickState mesures the time between two MouseDown and decide for a simple click if the time is > than HandMorph doubleClickTime.
> > When several tests with simulateClick are runned, then depending on the state of the hand MouseClickState, a simple click or a double click are triggered.
> > So it explains why when you run several tests some of then are failing.
> > But when you run a single test with a single simultateClick, then it doesn't fail.
> >
> > the lesson is that mouseClickState should not be shared (instance var of the HandMorph).
> > or it should test the target morph and not only the time.
> >
> >
> > the workarround is to wait before any simulateClick, I've tried and it works.
> > change the simulateClick method as follow and all your Rubric related tests should be green again.
> > --------
> > simulateClick
> >       (Delay forMilliseconds: HandMorph doubleClickTime + 1) wait.
> >       self simulateClickWith: MouseEvent redButton.
> > --------
> >
> > Cheers
> > Alain
> >
> >
> > Le 13 juil. 2013 à 17:26, Tudor Girba <[hidden email]> a écrit :
> >
> >> Wow, thank you very much for looking into this.
> >>
> >> Doru
> >>
> >>
> >> On Jul 13, 2013, at 3:14 PM, Alain Plantec <[hidden email]> wrote:
> >>
> >>> ok, I 've a track
> >>> With rubric, if a textArea do not have the focus but has a selection, then the first click on it give it the focus but don't deselect.
> >>> In that case, one have to click to times to have the old TextMorph behavior.
> >>> So, depending on the goal of the test, one have to send simulateClick one time or two times and not alway only one time.
> >>> I will dig more to really understand.
> >>>
> >>>
> >>> Le 13 juil. 2013 à 10:11, Alain Plantec <[hidden email]> a écrit :
> >>>
> >>>> and if one add a #inspect send in a testMethod, the results are the same with the TestRunner but differ
> >>>> if one run them from Nautilus.
> >>>> As an example, with:
> >>>> -----
> >>>> testEnteringTextInPort
> >>>>    | composite textMorph |
> >>>>    composite := GLMCompositePresentation new with: [ :a | a rubricText display: '' ].
> >>>>    window := composite openOn: 4.
> >>>>    textMorph := self find: RubScrolledTextMorph in: window.
> >>>>    textMorph simulateClick.
> >>>>    self assert: textMorph activeHand keyboardFocus = textMorph textArea.
> >>>>    self simulateKeyStrokes: 'hello'.
> >>>>     (composite pane port: #text) value asString inspect.  <-------------------------------- ** inspect added here **
> >>>>    self assert: (composite pane port: #text) value asString = 'hello'
> >>>> ----
> >>>> by running tests from Nautilus, the inspect runs ok and the result string is 'hello'.
> >>>> but now #testAcceptKeyCanBeOverriden turns yellow
> >>>>
> >>>> by running test from the TestRunner, #testEnteringTextInPort and #testPastingUpdatesTextPort stay yellow (as without the inspect)
> >>>> and #testAcceptKeyCanBeOverriden is green
> >>>>
> >>>> Alain
> >>>>
> >>>>
> >>>> Le 2 juil. 2013 à 12:49, Tudor Girba <[hidden email]> a écrit :
> >>>>
> >>>>> Thanks. I got the same problem and I do not know where to start from. It's really strange.
> >>>>>
> >>>>> For those interested, the tests are in the GLMRubricTextMorphicTest class. If you run all of them repeatedly, you get some errors. If you run them individually, you do not.
> >>>>>
> >>>>> Alain: do you happen to have an insight?
> >>>>>
> >>>>> Doru
> >>>>>
> >>>>>
> >>>>> On Tue, Jul 2, 2013 at 11:53 AM, Yuriy Tymchuk <[hidden email]> wrote:
> >>>>> Hi guys.
> >>>>>
> >>>>> I hope that we can release 4.8 and move to Pharo 3.0 soon. I wanted to fix failing tests and the only one is Rubric test. I was working with it for some time, and I have no idea what's up. When you run tests separately they work fine, but when being run in a suite some test fail and failures are inflicted by test order
> >>>>>
> >>>>> Maybe someone have ideas where to look at? UI maybe?
> >>>>>
> >>>>> Uko
> >>>>> _______________________________________________
> >>>>> Moose-dev mailing list
> >>>>> [hidden email]
> >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> www.tudorgirba.com
> >>>>>
> >>>>> "Every thing has its own flow"
> >>>>
> >>>>
> >>>
> >>
> >> --
> >> www.tudorgirba.com
> >>
> >> "If you interrupt the barber while he is cutting your hair,
> >> you will end up with a messy haircut."
> >>
> >>
> >
> >
>
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"

> Hi,
>
> In the meantime, I added a utility method in GLMRubricTextMorphicTest:
>
> simulateOnlyOneClickOn: aMorph
> (Delay forMilliseconds: HandMorph doubleClickTime + 1) wait.
> aMorph simulateClick
>
> We should integrate this utility in Pharo 3.0.
>
> All tests are green locally. Let's see how it goes on the server.
>
> Cheers,
> Doru
>
>
> On Jul 15, 2013, at 8:57 AM, Tudor Girba <[hidden email]> wrote:
>
>> This sounds good. I would call the block method as ignoreMultipleClicksWhile:.
>>
>> Doru
>>
>>
>> On Mon, Jul 15, 2013 at 8:43 AM, Alain Plantec <[hidden email]> wrote:
>> maybe another solution would be to unplug the hand mouseclickstate before sending the event and to replug it after.
>> something like:
>>
>> --------
>> simulateClick
>>        self activeHand forbidMultipleClickWhile: [
>>                self simulateClickWith: MouseEvent redButton]
>> --------
>> it would be much more efficient.
>> I will make a try.
>> Alain
>>
>>
>> Le 14 juil. 2013 à 21:26, Alain Plantec <[hidden email]> a écrit :
>>
>>> yep, caught.
>>> and finally it is funny :)
>>>
>>> It has something to do with #simulateClick.
>>> In Rubric, MouseClickState is used to have a real doubleClick (whereas in TextMorph, the editor handle click/doubleClick by itself and not with MouseClickState).
>>> Mouse clickState mesures the time between two MouseDown and decide for a simple click if the time is > than HandMorph doubleClickTime.
>>> When several tests with simulateClick are runned, then depending on the state of the hand MouseClickState, a simple click or a double click are triggered.
>>> So it explains why when you run several tests some of then are failing.
>>> But when you run a single test with a single simultateClick, then it doesn't fail.
>>>
>>> the lesson is that mouseClickState should not be shared (instance var of the HandMorph).
>>> or it should test the target morph and not only the time.
>>>
>>>
>>> the workarround is to wait before any simulateClick, I've tried and it works.
>>> change the simulateClick method as follow and all your Rubric related tests should be green again.
>>> --------
>>> simulateClick
>>>      (Delay forMilliseconds: HandMorph doubleClickTime + 1) wait.
>>>      self simulateClickWith: MouseEvent redButton.
>>> --------
>>>
>>> Cheers
>>> Alain
>>>
>>>
>>> Le 13 juil. 2013 à 17:26, Tudor Girba <[hidden email]> a écrit :
>>>
>>>> Wow, thank you very much for looking into this.
>>>>
>>>> Doru
>>>>
>>>>
>>>> On Jul 13, 2013, at 3:14 PM, Alain Plantec <[hidden email]> wrote:
>>>>
>>>>> ok, I 've a track
>>>>> With rubric, if a textArea do not have the focus but has a selection, then the first click on it give it the focus but don't deselect.
>>>>> In that case, one have to click to times to have the old TextMorph behavior.
>>>>> So, depending on the goal of the test, one have to send simulateClick one time or two times and not alway only one time.
>>>>> I will dig more to really understand.
>>>>>
>>>>>
>>>>> Le 13 juil. 2013 à 10:11, Alain Plantec <[hidden email]> a écrit :
>>>>>
>>>>>> and if one add a #inspect send in a testMethod, the results are the same with the TestRunner but differ
>>>>>> if one run them from Nautilus.
>>>>>> As an example, with:
>>>>>> -----
>>>>>> testEnteringTextInPort
>>>>>>   | composite textMorph |
>>>>>>   composite := GLMCompositePresentation new with: [ :a | a rubricText display: '' ].
>>>>>>   window := composite openOn: 4.
>>>>>>   textMorph := self find: RubScrolledTextMorph in: window.
>>>>>>   textMorph simulateClick.
>>>>>>   self assert: textMorph activeHand keyboardFocus = textMorph textArea.
>>>>>>   self simulateKeyStrokes: 'hello'.
>>>>>>    (composite pane port: #text) value asString inspect.  <-------------------------------- ** inspect added here **
>>>>>>   self assert: (composite pane port: #text) value asString = 'hello'
>>>>>> ----
>>>>>> by running tests from Nautilus, the inspect runs ok and the result string is 'hello'.
>>>>>> but now #testAcceptKeyCanBeOverriden turns yellow
>>>>>>
>>>>>> by running test from the TestRunner, #testEnteringTextInPort and #testPastingUpdatesTextPort stay yellow (as without the inspect)
>>>>>> and #testAcceptKeyCanBeOverriden is green
>>>>>>
>>>>>> Alain
>>>>>>
>>>>>>
>>>>>> Le 2 juil. 2013 à 12:49, Tudor Girba <[hidden email]> a écrit :
>>>>>>
>>>>>>> Thanks. I got the same problem and I do not know where to start from. It's really strange.
>>>>>>>
>>>>>>> For those interested, the tests are in the GLMRubricTextMorphicTest class. If you run all of them repeatedly, you get some errors. If you run them individually, you do not.
>>>>>>>
>>>>>>> Alain: do you happen to have an insight?
>>>>>>>
>>>>>>> Doru
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 2, 2013 at 11:53 AM, Yuriy Tymchuk <[hidden email]> wrote:
>>>>>>> Hi guys.
>>>>>>>
>>>>>>> I hope that we can release 4.8 and move to Pharo 3.0 soon. I wanted to fix failing tests and the only one is Rubric test. I was working with it for some time, and I have no idea what's up. When you run tests separately they work fine, but when being run in a suite some test fail and failures are inflicted by test order
>>>>>>>
>>>>>>> Maybe someone have ideas where to look at? UI maybe?
>>>>>>>
>>>>>>> Uko
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> www.tudorgirba.com
>>>>>>>
>>>>>>> "Every thing has its own flow"
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "If you interrupt the barber while he is cutting your hair,
>>>> you will end up with a messy haircut."
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>
> --
> www.tudorgirba.com
>
> "Next time you see your life passing by, say 'hi' and get to know her."
>
>
>