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
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi all, I will have a look. Cheers Alain
Le 2 juil. 2013 à 12:49, Tudor Girba tudor@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
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@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@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@iam.unibe.ch 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 tudor@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@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@iam.unibe.ch 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 alain.plantec@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@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@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@iam.unibe.ch 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 alain.plantec@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@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@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@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@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."
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@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@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@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@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@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@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."
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 alain.plantec@univ-brest.fr 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 tudor@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@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@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@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@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@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."
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
-
Alain Plantec -
Stephan Eggermont -
Tudor Girba -
Yuriy Tymchuk