Rubric test failures - Moose-dev

Tudor Girba

2 Jul 2 Jul

12:49 p.m.

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 <yuriy.tymchuk(a)me.com> 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 Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "Every thing has its own flow"

Reply

Alain Plantec

13 Jul 13 Jul

9:18 a.m.

Hi, I've checked and yes this is a strange problem. I've tried to duplicate problematic test methods: just added testEnteringTextInPort2 with the same code as testEnteringTextInPort and added testExplicitAcceptDoesNotAffectTextPort2 with the same code as testExplicitAcceptDoesNotAffectTextPort then the test results differ. before: 2 tests are failing (yellow) testEnteringTextInPort fails (yellow) testExplicitAcceptDoesNotAffectTextPort fails (yellow) after: 3 tests are failing (yellow) testEnteringTextInPort testExplicitAcceptDoesNotAffectTextPort testPastingUpdatesTextPort and very strange, testEnteringTextInPort2 and testExplicitAcceptDoesNotAffectTextPort are green. Test results seem to differ randomly when one duplicate test methods. Another strange thing is that I did'nt find String>>#equals: (I only have a method #equals: in Zinc). Something wrong with the test framework ? Cheers Alain Le 2 juil. 2013 à 12:49, Tudor Girba <tudor(a)tudorgirba.com> 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 <yuriy.tymchuk(a)me.com> 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 Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow"

Reply

Alain Plantec

3:14 p.m.

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 <alain.plantec(a)univ-brest.fr> 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 <tudor(a)tudorgirba.com> 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 <yuriy.tymchuk(a)me.com> 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 Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow"

Reply

Alain Plantec

14 Jul 14 Jul

9:26 p.m.

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 <tudor(a)tudorgirba.com> a écrit :

...

Wow, thank you very much for looking into this. Doru On Jul 13, 2013, at 3:14 PM, Alain Plantec <alain.plantec(a)univ-brest.fr> 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 <alain.plantec(a)univ-brest.fr> 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 <tudor(a)tudorgirba.com> 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 <yuriy.tymchuk(a)me.com> 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 Moose-dev(a)iam.unibe.ch 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."

Reply

Stephan Eggermont

13 Jul 13 Jul

7:42 p.m.

On 13 jul 2013, at 15:14, Alain Plantec 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.

That sounds like correct behaviour. I just checked Mac OS X behaviour. If I have a text selection in TextEdit and another window (or another application) has focus, Clicking on the text area of the window with the text selection does the same. Mouse down over the selection and wait a short time starts a drag action. Mouse down while moving over the text selection just gives focus. Only second click changes the cursor position. Stephan

Reply