Re: UI tests opening all possible dialogs

2019-06-26 Thread Artur Neumann 
Hi Raal,

please have a look at the newest version of
https://gerrit.libreoffice.org/#/c/74333/

I've added tests of the "cancel" button to wherever other tests check
the work of that specific dialog.
As far as possible I tried not to open new documents for the new test,
but integrate into the existing tests.
Wherever it was easy I've added a short check if the "cancel" button
does not change anything obvious.

Greetings Artur

On 2019-06-25 9:02 p.m., Raal wrote:
> Hi Artur,
> yes, because longest time of uitest is initialize and open LibreOffice.
> Thank you
> Regards,
> Raal
>
> On 25. 06. 19 13:30, Artur Neumann wrote:
>>
>> Hi Raal,
>>
>> so you would prefer if the "Cancel/Close" tests would be integrated
>> in other tests of that dialog if those exist like I've done now
>>
>> https://gerrit.libreoffice.org/#/c/74333/9/sc/qa/uitest/calc_tests/fillRandomNumber.py
>> https://gerrit.libreoffice.org/#/c/74333/9/sc/qa/uitest/calc_tests/sheetRename.py
>> https://gerrit.libreoffice.org/#/c/74333/9/sc/qa/uitest/calc_tests3/clearCells.py
>>
>> If that is the case I will go through the list and change that
>>
>> Artur
>>
>> On 2019-06-24 9:30 p.m., Raal wrote:
>>> Hi Artur,
>>> see https://gerrit.libreoffice.org/#/c/74654/ - you can add test for
>>> Cancel button to existing tests.
>>>
>>> Cheers,
>>> Raal
>>>
>>> On 24. 06. 19 9:22, Artur Neumann wrote:

 Hi Raal & Markus

 I've moved the tests into a new folder and skipped tests that are
 already done in other tests. The lines have comments explaining why
 specific tests are skipped. https://gerrit.libreoffice.org/#/c/74333/

 If you thing testing the "Cancel" button does not make sense, we
 can skip even more tests.

 Please review and see if that makes sense to you.

 Greetings Artur

 On 2019-06-22 10:57 p.m., Raal wrote:
> Hello Artur,
> generally it looks useful, but please check first if such test
> exists. For example bug 120227 is already covered by this test
> https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/pageFormat/tdf123508
> .py .
> Please search first at opengrok, because uitests are quite slow
> and we should avoid duplicity. For example from your test
> SearchDialog  - lots of tests exists in directory
> /core/sc/qa/uitest/search_replace/
> 
> InsertObjectChart - lots of tests exists in directory 
> /core/sc/qa/uitest/chart/
> FunctionDialog -
> https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/calc_tests7/tdf123479.py
> etc.
>
> Please add your test to the new directory, see
> https://gerrit.libreoffice.org/#/c/72376/ like an example
> Note: the tests runs in "gen" enviroment, so gtk3 bugs we cannot
> test (125982
> ,
> 125985 )
>
> Best regards,
> Raal
>
>
>
>
> On 22. 06. 19 11:10, Markus Mohrhard wrote:
>> Hello Artur,
>>
>> On Fri, Jun 21, 2019 at 12:06 PM Artur Neumann
>> mailto:ar...@jankaritech.com>> wrote:
>>
>> Forgot the link to the changes, here it is:
>> https://gerrit.libreoffice.org/#/c/74333/
>>
>> On 2019-06-20 5:01 p.m., Artur Neumann wrote:
>>>
>>> I've made some UI tests that open every dialog in calc,
>>> close it with the "close" or "cancel" button and if there is
>>> an "OK" button open it again and click the "OK" button
>>>
>>> These tests should simply make sure there are no crashes by
>>> opening/closing the dialogues and protect against
>>> regressions like
>>> https://bugs.documentfoundation.org/show_bug.cgi?id=120227
>>> https://bugs.documentfoundation.org/show_bug.cgi?id=125982
>>> https://bugs.documentfoundation.org/show_bug.cgi?id=125985
>>>
>>> I just wanted to have some feedback if picking those
>>> low-hanging fruits is a valid approach and worth the effort
>>> and CI time.
>>>
>>
>> I think that in general it is a good idea. Depending on how long
>> it takes to execute the test we might need to think about whether
>> we can actually include the tests in a normal make/make check or
>> if they need to be treated differently. Did you already have a
>> chat with Raal who has been writing tests for many bugs/dialogs
>> already?
>>
>>> If yes I could extend the tests by:
>>>
>>>  1. doing the same for writer, impress, etc.
>>>  2. delete obsolete tests like uitest/calc_tests/about_test.py
>>>  3. define preconditions for the "OK" click, e.g. input data
>>> into fields
>>>  4. define assertion after the click on the "OK" button

Re: UI tests opening all possible dialogs

2019-06-25 Thread Raal 

Hi Artur,
yes, because longest time of uitest is initialize and open LibreOffice.
Thank you
Regards,
Raal

On 25. 06. 19 13:30, Artur Neumann wrote:


Hi Raal,

so you would prefer if the "Cancel/Close" tests would be integrated in 
other tests of that dialog if those exist like I've done now


https://gerrit.libreoffice.org/#/c/74333/9/sc/qa/uitest/calc_tests/fillRandomNumber.py
https://gerrit.libreoffice.org/#/c/74333/9/sc/qa/uitest/calc_tests/sheetRename.py
https://gerrit.libreoffice.org/#/c/74333/9/sc/qa/uitest/calc_tests3/clearCells.py

If that is the case I will go through the list and change that

Artur

On 2019-06-24 9:30 p.m., Raal wrote:

Hi Artur,
see https://gerrit.libreoffice.org/#/c/74654/ - you can add test for 
Cancel button to existing tests.


Cheers,
Raal

On 24. 06. 19 9:22, Artur Neumann wrote:


Hi Raal & Markus

I've moved the tests into a new folder and skipped tests that are 
already done in other tests. The lines have comments explaining why 
specific tests are skipped. https://gerrit.libreoffice.org/#/c/74333/


If you thing testing the "Cancel" button does not make sense, we can 
skip even more tests.


Please review and see if that makes sense to you.

Greetings Artur

On 2019-06-22 10:57 p.m., Raal wrote:

Hello Artur,
generally it looks useful, but please check first if such test 
exists. For example bug 120227 is already covered by this test 
https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/pageFormat/tdf123508 
.py .
Please search first at opengrok, because uitests are quite slow and 
we should avoid duplicity. For example from your test
SearchDialog  - lots of tests exists in directory 
/core/sc/qa/uitest/search_replace/ 

InsertObjectChart - lots of tests exists in directory 
/core/sc/qa/uitest/chart/
FunctionDialog - 
https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/calc_tests7/tdf123479.py

etc.

Please add your test to the new directory, see 
https://gerrit.libreoffice.org/#/c/72376/ like an example
Note: the tests runs in "gen" enviroment, so gtk3 bugs we cannot 
test (125982 
, 
125985 )


Best regards,
Raal




On 22. 06. 19 11:10, Markus Mohrhard wrote:

Hello Artur,

On Fri, Jun 21, 2019 at 12:06 PM Artur Neumann 
mailto:ar...@jankaritech.com>> wrote:


Forgot the link to the changes, here it is:
https://gerrit.libreoffice.org/#/c/74333/

On 2019-06-20 5:01 p.m., Artur Neumann wrote:


I've made some UI tests that open every dialog in calc, close
it with the "close" or "cancel" button and if there is an
"OK" button open it again and click the "OK" button

These tests should simply make sure there are no crashes by
opening/closing the dialogues and protect against regressions
like
https://bugs.documentfoundation.org/show_bug.cgi?id=120227
https://bugs.documentfoundation.org/show_bug.cgi?id=125982
https://bugs.documentfoundation.org/show_bug.cgi?id=125985

I just wanted to have some feedback if picking those
low-hanging fruits is a valid approach and worth the effort
and CI time.



I think that in general it is a good idea. Depending on how long 
it takes to execute the test we might need to think about whether 
we can actually include the tests in a normal make/make check or 
if they need to be treated differently. Did you already have a 
chat with Raal who has been writing tests for many bugs/dialogs 
already?



If yes I could extend the tests by:

 1. doing the same for writer, impress, etc.
 2. delete obsolete tests like uitest/calc_tests/about_test.py
 3. define preconditions for the "OK" click, e.g. input data
into fields
 4. define assertion after the click on the "OK" button



In general this sounds like a good idea. As mentioned it might be 
good to have a chat with Raal who might have an overview how far 
we are in opening all dialogs already.


Regards,
Markus


Thoughts? Ideas?

-- 
Artur Neumann

Director/CTO
Jankari Tech Pvt Ltd
www.jankaritech.com  
Phone: +977 9806639223
Skype: artur.n.
GitHub:https://github.com/individual-it

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org  

https://lists.freedesktop.org/mailman/listinfo/libreoffice


-- 
Artur Neumann

Director/CTO
Jankari Tech Pvt Ltd
www.jankaritech.com  
Phone: +977 9806639223
Skype: artur.n.
GitHub:https://github.com/individual-it

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org

Re: UI tests opening all possible dialogs

2019-06-25 Thread Artur Neumann 
Hi Raal,

so you would prefer if the "Cancel/Close" tests would be integrated in
other tests of that dialog if those exist like I've done now

https://gerrit.libreoffice.org/#/c/74333/9/sc/qa/uitest/calc_tests/fillRandomNumber.py
https://gerrit.libreoffice.org/#/c/74333/9/sc/qa/uitest/calc_tests/sheetRename.py
https://gerrit.libreoffice.org/#/c/74333/9/sc/qa/uitest/calc_tests3/clearCells.py

If that is the case I will go through the list and change that

Artur

On 2019-06-24 9:30 p.m., Raal wrote:
> Hi Artur,
> see https://gerrit.libreoffice.org/#/c/74654/ - you can add test for
> Cancel button to existing tests.
>
> Cheers,
> Raal
>
> On 24. 06. 19 9:22, Artur Neumann wrote:
>>
>> Hi Raal & Markus
>>
>> I've moved the tests into a new folder and skipped tests that are
>> already done in other tests. The lines have comments explaining why
>> specific tests are skipped. https://gerrit.libreoffice.org/#/c/74333/
>>
>> If you thing testing the "Cancel" button does not make sense, we can
>> skip even more tests.
>>
>> Please review and see if that makes sense to you.
>>
>> Greetings Artur
>>
>> On 2019-06-22 10:57 p.m., Raal wrote:
>>> Hello Artur,
>>> generally it looks useful, but please check first if such test
>>> exists. For example bug 120227 is already covered by this test
>>> https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/pageFormat/tdf123508
>>> .py .
>>> Please search first at opengrok, because uitests are quite slow and
>>> we should avoid duplicity. For example from your test
>>> SearchDialog  - lots of tests exists in directory
>>> /core/sc/qa/uitest/search_replace/
>>> 
>>> InsertObjectChart - lots of tests exists in directory 
>>> /core/sc/qa/uitest/chart/
>>> FunctionDialog -
>>> https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/calc_tests7/tdf123479.py
>>> etc.
>>>
>>> Please add your test to the new directory, see
>>> https://gerrit.libreoffice.org/#/c/72376/ like an example
>>> Note: the tests runs in "gen" enviroment, so gtk3 bugs we cannot
>>> test (125982
>>> , 125985
>>> )
>>>
>>> Best regards,
>>> Raal
>>>
>>>
>>>
>>>
>>> On 22. 06. 19 11:10, Markus Mohrhard wrote:
 Hello Artur,

 On Fri, Jun 21, 2019 at 12:06 PM Artur Neumann
 mailto:ar...@jankaritech.com>> wrote:

 Forgot the link to the changes, here it is:
 https://gerrit.libreoffice.org/#/c/74333/

 On 2019-06-20 5:01 p.m., Artur Neumann wrote:
>
> I've made some UI tests that open every dialog in calc, close
> it with the "close" or "cancel" button and if there is an "OK"
> button open it again and click the "OK" button
>
> These tests should simply make sure there are no crashes by
> opening/closing the dialogues and protect against regressions
> like
> https://bugs.documentfoundation.org/show_bug.cgi?id=120227
> https://bugs.documentfoundation.org/show_bug.cgi?id=125982
> https://bugs.documentfoundation.org/show_bug.cgi?id=125985
>
> I just wanted to have some feedback if picking those
> low-hanging fruits is a valid approach and worth the effort
> and CI time.
>

 I think that in general it is a good idea. Depending on how long it
 takes to execute the test we might need to think about whether we
 can actually include the tests in a normal make/make check or if
 they need to be treated differently. Did you already have a chat
 with Raal who has been writing tests for many bugs/dialogs already?

> If yes I could extend the tests by:
>
>  1. doing the same for writer, impress, etc.
>  2. delete obsolete tests like uitest/calc_tests/about_test.py
>  3. define preconditions for the "OK" click, e.g. input data
> into fields
>  4. define assertion after the click on the "OK" button
>

 In general this sounds like a good idea. As mentioned it might be
 good to have a chat with Raal who might have an overview how far we
 are in opening all dialogs already.

 Regards,
 Markus

> Thoughts? Ideas?
>
> -- 
> Artur Neumann
> Director/CTO
> Jankari Tech Pvt Ltd
> www.jankaritech.com 
> Phone: +977 9806639223
> Skype: artur.n.
> GitHub: https://github.com/individual-it
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org 
> 
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

 -- 
 Artur Neumann
 Director/CTO

Re: UI tests opening all possible dialogs

2019-06-24 Thread Raal 

Hi Artur,
see https://gerrit.libreoffice.org/#/c/74654/ - you can add test for 
Cancel button to existing tests.


Cheers,
Raal

On 24. 06. 19 9:22, Artur Neumann wrote:


Hi Raal & Markus

I've moved the tests into a new folder and skipped tests that are 
already done in other tests. The lines have comments explaining why 
specific tests are skipped. https://gerrit.libreoffice.org/#/c/74333/


If you thing testing the "Cancel" button does not make sense, we can 
skip even more tests.


Please review and see if that makes sense to you.

Greetings Artur

On 2019-06-22 10:57 p.m., Raal wrote:

Hello Artur,
generally it looks useful, but please check first if such test 
exists. For example bug 120227 is already covered by this test 
https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/pageFormat/tdf123508 
.py .
Please search first at opengrok, because uitests are quite slow and 
we should avoid duplicity. For example from your test
SearchDialog  - lots of tests exists in directory 
/core/sc/qa/uitest/search_replace/ 

InsertObjectChart - lots of tests exists in directory 
/core/sc/qa/uitest/chart/
FunctionDialog - 
https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/calc_tests7/tdf123479.py

etc.

Please add your test to the new directory, see 
https://gerrit.libreoffice.org/#/c/72376/ like an example
Note: the tests runs in "gen" enviroment, so gtk3 bugs we cannot test 
(125982 , 
125985 )


Best regards,
Raal




On 22. 06. 19 11:10, Markus Mohrhard wrote:

Hello Artur,

On Fri, Jun 21, 2019 at 12:06 PM Artur Neumann 
mailto:ar...@jankaritech.com>> wrote:


Forgot the link to the changes, here it is:
https://gerrit.libreoffice.org/#/c/74333/

On 2019-06-20 5:01 p.m., Artur Neumann wrote:


I've made some UI tests that open every dialog in calc, close
it with the "close" or "cancel" button and if there is an "OK"
button open it again and click the "OK" button

These tests should simply make sure there are no crashes by
opening/closing the dialogues and protect against regressions like
https://bugs.documentfoundation.org/show_bug.cgi?id=120227
https://bugs.documentfoundation.org/show_bug.cgi?id=125982
https://bugs.documentfoundation.org/show_bug.cgi?id=125985

I just wanted to have some feedback if picking those
low-hanging fruits is a valid approach and worth the effort and
CI time.



I think that in general it is a good idea. Depending on how long it 
takes to execute the test we might need to think about whether we 
can actually include the tests in a normal make/make check or if 
they need to be treated differently. Did you already have a chat 
with Raal who has been writing tests for many bugs/dialogs already?



If yes I could extend the tests by:

 1. doing the same for writer, impress, etc.
 2. delete obsolete tests like uitest/calc_tests/about_test.py
 3. define preconditions for the "OK" click, e.g. input data
into fields
 4. define assertion after the click on the "OK" button



In general this sounds like a good idea. As mentioned it might be 
good to have a chat with Raal who might have an overview how far we 
are in opening all dialogs already.


Regards,
Markus


Thoughts? Ideas?

-- 
Artur Neumann

Director/CTO
Jankari Tech Pvt Ltd
www.jankaritech.com  
Phone: +977 9806639223
Skype: artur.n.
GitHub:https://github.com/individual-it

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org  

https://lists.freedesktop.org/mailman/listinfo/libreoffice


-- 
Artur Neumann

Director/CTO
Jankari Tech Pvt Ltd
www.jankaritech.com  
Phone: +977 9806639223
Skype: artur.n.
GitHub:https://github.com/individual-it

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org

https://lists.freedesktop.org/mailman/listinfo/libreoffice




--
LibreOffice is powered by a team of volunteers who mostly give their time for 
free.
We invite you to join as there are many ways to get involved including bugs 
triage,
marketing, UX, documentation, and of course developing 
-https://www.libreoffice.org/get-involved/

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

--
Artur Neumann
Director/CTO
Jankari Tech Pvt Ltd
www.jankaritech.com
Phone: +977 9806639223
Skype: artur.n.
GitHub:https://github.com/individual-it



--

Re: UI tests opening all possible dialogs

2019-06-24 Thread Artur Neumann 
Hi Raal & Markus

I've moved the tests into a new folder and skipped tests that are
already done in other tests. The lines have comments explaining why
specific tests are skipped. https://gerrit.libreoffice.org/#/c/74333/

If you thing testing the "Cancel" button does not make sense, we can
skip even more tests.

Please review and see if that makes sense to you.

Greetings Artur

On 2019-06-22 10:57 p.m., Raal wrote:
> Hello Artur,
> generally it looks useful, but please check first if such test exists.
> For example bug 120227 is already covered by this test
> https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/pageFormat/tdf123508
> .py .
> Please search first at opengrok, because uitests are quite slow and we
> should avoid duplicity. For example from your test
> SearchDialog  - lots of tests exists in directory
> /core/sc/qa/uitest/search_replace/
> 
> InsertObjectChart - lots of tests exists in directory 
> /core/sc/qa/uitest/chart/
> FunctionDialog -
> https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/calc_tests7/tdf123479.py
> etc.
>
> Please add your test to the new directory, see
> https://gerrit.libreoffice.org/#/c/72376/ like an example
> Note: the tests runs in "gen" enviroment, so gtk3 bugs we cannot test
> (125982 ,
> 125985 )
>
> Best regards,
> Raal
>
>
>
>
> On 22. 06. 19 11:10, Markus Mohrhard wrote:
>> Hello Artur,
>>
>> On Fri, Jun 21, 2019 at 12:06 PM Artur Neumann > > wrote:
>>
>> Forgot the link to the changes, here it is:
>> https://gerrit.libreoffice.org/#/c/74333/
>>
>> On 2019-06-20 5:01 p.m., Artur Neumann wrote:
>>>
>>> I've made some UI tests that open every dialog in calc, close it
>>> with the "close" or "cancel" button and if there is an "OK"
>>> button open it again and click the "OK" button
>>>
>>> These tests should simply make sure there are no crashes by
>>> opening/closing the dialogues and protect against regressions like
>>> https://bugs.documentfoundation.org/show_bug.cgi?id=120227
>>> https://bugs.documentfoundation.org/show_bug.cgi?id=125982
>>> https://bugs.documentfoundation.org/show_bug.cgi?id=125985
>>>
>>> I just wanted to have some feedback if picking those low-hanging
>>> fruits is a valid approach and worth the effort and CI time.
>>>
>>
>> I think that in general it is a good idea. Depending on how long it
>> takes to execute the test we might need to think about whether we can
>> actually include the tests in a normal make/make check or if they
>> need to be treated differently. Did you already have a chat with Raal
>> who has been writing tests for many bugs/dialogs already?
>>
>>> If yes I could extend the tests by:
>>>
>>>  1. doing the same for writer, impress, etc.
>>>  2. delete obsolete tests like uitest/calc_tests/about_test.py
>>>  3. define preconditions for the "OK" click, e.g. input data
>>> into fields
>>>  4. define assertion after the click on the "OK" button
>>>
>>
>> In general this sounds like a good idea. As mentioned it might be
>> good to have a chat with Raal who might have an overview how far we
>> are in opening all dialogs already.
>>
>> Regards,
>> Markus
>>
>>> Thoughts? Ideas?
>>>
>>> -- 
>>> Artur Neumann
>>> Director/CTO
>>> Jankari Tech Pvt Ltd
>>> www.jankaritech.com 
>>> Phone: +977 9806639223
>>> Skype: artur.n.
>>> GitHub: https://github.com/individual-it
>>>
>>> ___
>>> LibreOffice mailing list
>>> LibreOffice@lists.freedesktop.org 
>>> 
>>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>>
>> -- 
>> Artur Neumann
>> Director/CTO
>> Jankari Tech Pvt Ltd
>> www.jankaritech.com 
>> Phone: +977 9806639223
>> Skype: artur.n.
>> GitHub: https://github.com/individual-it
>>
>> ___
>> LibreOffice mailing list
>> LibreOffice@lists.freedesktop.org
>> 
>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>>
>
>
> -- 
> LibreOffice is powered by a team of volunteers who mostly give their time for 
> free. 
> We invite you to join as there are many ways to get involved including bugs 
> triage, 
> marketing, UX, documentation, and of course developing -  
> https://www.libreoffice.org/get-involved/
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

-- 
Artur Neumann
Director/CTO
Jankari Tech

Re: UI tests opening all possible dialogs

2019-06-23 Thread Artur Neumann 
Hi Raal,

thank you for the advice. I thought of deleting obsolete tests like
uitest/calc_tests/about_test.py in the second step. But its true, as the
more complex tests have to be kept anywhere some of the simple tests in
my commit can be deleted.

The question is though if in some cases they still might be valid. e.g.
https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/calc_tests7/tdf123479.py

 1. does not check the "Cancel" button
 2. opens a document and selects a range before opening the dialog,
meaning testing an other scenario

I don't know enough of LO structure and what areas are bug-prone, to
make a judgment on whether in such a case an extra "Open dialog, click
cancel" and "Open dialog on an empty sheet, click OK" tests are worth
having.

What I will do then:

 1. go through the tests in https://gerrit.libreoffice.org/#/c/74333
 and check which look not
needed
 2. place it in a nee directory
 3. cleanup the list of tests marked "needUITest" in bugzilla

https://bugs.documentfoundation.org/buglist.cgi?include_fields=id_fields=summary_fields=priority_fields=status=needUITest_id=972536=bug_id=LibreOffice=FIXED
I had a go at some and found that tests already exists
 4. close https://gerrit.libreoffice.org/#/c/74026/

Greetings Artur

On 2019-06-22 10:57 p.m., Raal wrote:
> Hello Artur,
> generally it looks useful, but please check first if such test exists.
> For example bug 120227 is already covered by this test
> https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/pageFormat/tdf123508
> .py .
> Please search first at opengrok, because uitests are quite slow and we
> should avoid duplicity. For example from your test
> SearchDialog  - lots of tests exists in directory
> /core/sc/qa/uitest/search_replace/
> 
> InsertObjectChart - lots of tests exists in directory 
> /core/sc/qa/uitest/chart/
> FunctionDialog -
> https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/calc_tests7/tdf123479.py
> etc.
>
> Please add your test to the new directory, see
> https://gerrit.libreoffice.org/#/c/72376/ like an example
> Note: the tests runs in "gen" enviroment, so gtk3 bugs we cannot test
> (125982 ,
> 125985 )
>
> Best regards,
> Raal
>
>
>
>
> On 22. 06. 19 11:10, Markus Mohrhard wrote:
>> Hello Artur,
>>
>> On Fri, Jun 21, 2019 at 12:06 PM Artur Neumann > > wrote:
>>
>> Forgot the link to the changes, here it is:
>> https://gerrit.libreoffice.org/#/c/74333/
>>
>> On 2019-06-20 5:01 p.m., Artur Neumann wrote:
>>>
>>> I've made some UI tests that open every dialog in calc, close it
>>> with the "close" or "cancel" button and if there is an "OK"
>>> button open it again and click the "OK" button
>>>
>>> These tests should simply make sure there are no crashes by
>>> opening/closing the dialogues and protect against regressions like
>>> https://bugs.documentfoundation.org/show_bug.cgi?id=120227
>>> https://bugs.documentfoundation.org/show_bug.cgi?id=125982
>>> https://bugs.documentfoundation.org/show_bug.cgi?id=125985
>>>
>>> I just wanted to have some feedback if picking those low-hanging
>>> fruits is a valid approach and worth the effort and CI time.
>>>
>>
>> I think that in general it is a good idea. Depending on how long it
>> takes to execute the test we might need to think about whether we can
>> actually include the tests in a normal make/make check or if they
>> need to be treated differently. Did you already have a chat with Raal
>> who has been writing tests for many bugs/dialogs already?
>>
>>> If yes I could extend the tests by:
>>>
>>>  1. doing the same for writer, impress, etc.
>>>  2. delete obsolete tests like uitest/calc_tests/about_test.py
>>>  3. define preconditions for the "OK" click, e.g. input data
>>> into fields
>>>  4. define assertion after the click on the "OK" button
>>>
>>
>> In general this sounds like a good idea. As mentioned it might be
>> good to have a chat with Raal who might have an overview how far we
>> are in opening all dialogs already.
>>
>> Regards,
>> Markus
>>
>>> Thoughts? Ideas?
>>>
>>> -- 
>>> Artur Neumann
>>> Director/CTO
>>> Jankari Tech Pvt Ltd
>>> www.jankaritech.com 
>>> Phone: +977 9806639223
>>> Skype: artur.n.
>>> GitHub: https://github.com/individual-it
>>>
>>> ___
>>> LibreOffice mailing list
>>> LibreOffice@lists.freedesktop.org 
>>> 
>>> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>>
>> -- 
>> Artur Neumann
>> Director/CTO
>>

Re: UI tests opening all possible dialogs

2019-06-23 Thread Artur Neumann 
Hi,

I didn't had  contact with Raal yet. Added him and you to the reviewers
list.
It takes around 3min to run all tests of the commit on my laptop
(i5-4200U CPU @ 1.60GHz) and showing the UI. Using (LibreOffice Version:
6.3.0.0.beta1+
Build ID: 4904391e125eb66304a5c029def8d4c1a150952d)

Currently I'm compiling LO to see how long it takes with the make command.

Is there currently a way to run specific tests on nightly builds?

Am 22.06.19 um 14:55 schrieb Markus Mohrhard:
> Hello Artur,
>
> On Fri, Jun 21, 2019 at 12:06 PM Artur Neumann  > wrote:
>
> Forgot the link to the changes, here it is:
> https://gerrit.libreoffice.org/#/c/74333/
>
> On 2019-06-20 5:01 p.m., Artur Neumann wrote:
>>
>> I've made some UI tests that open every dialog in calc, close it
>> with the "close" or "cancel" button and if there is an "OK"
>> button open it again and click the "OK" button
>>
>> These tests should simply make sure there are no crashes by
>> opening/closing the dialogues and protect against regressions like
>> https://bugs.documentfoundation.org/show_bug.cgi?id=120227
>> https://bugs.documentfoundation.org/show_bug.cgi?id=125982
>> https://bugs.documentfoundation.org/show_bug.cgi?id=125985
>>
>> I just wanted to have some feedback if picking those low-hanging
>> fruits is a valid approach and worth the effort and CI time.
>>
>
> I think that in general it is a good idea. Depending on how long it
> takes to execute the test we might need to think about whether we can
> actually include the tests in a normal make/make check or if they need
> to be treated differently. Did you already have a chat with Raal who
> has been writing tests for many bugs/dialogs already?
>
>> If yes I could extend the tests by:
>>
>>  1. doing the same for writer, impress, etc.
>>  2. delete obsolete tests like uitest/calc_tests/about_test.py
>>  3. define preconditions for the "OK" click, e.g. input data into
>> fields
>>  4. define assertion after the click on the "OK" button
>>
>
> In general this sounds like a good idea. As mentioned it might be good
> to have a chat with Raal who might have an overview how far we are in
> opening all dialogs already.
>
> Regards,
> Markus
>
>> Thoughts? Ideas?
>>

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: UI tests opening all possible dialogs

2019-06-23 Thread Raal 

Hello Artur,
generally it looks useful, but please check first if such test exists. 
For example bug 120227 is already covered by this test 
https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/pageFormat/tdf123508 
.py .
Please search first at opengrok, because uitests are quite slow and we 
should avoid duplicity. For example from your test
SearchDialog  - lots of tests exists in directory 
/core/sc/qa/uitest/search_replace/ 

InsertObjectChart - lots of tests exists in directory 
/core/sc/qa/uitest/chart/
FunctionDialog - 
https://opengrok.libreoffice.org/xref/core/sc/qa/uitest/calc_tests7/tdf123479.py

etc.

Please add your test to the new directory, see 
https://gerrit.libreoffice.org/#/c/72376/ like an example
Note: the tests runs in "gen" enviroment, so gtk3 bugs we cannot test 
(125982 , 
125985 )


Best regards,
Raal




On 22. 06. 19 11:10, Markus Mohrhard wrote:

Hello Artur,

On Fri, Jun 21, 2019 at 12:06 PM Artur Neumann > wrote:


Forgot the link to the changes, here it is:
https://gerrit.libreoffice.org/#/c/74333/

On 2019-06-20 5:01 p.m., Artur Neumann wrote:


I've made some UI tests that open every dialog in calc, close it
with the "close" or "cancel" button and if there is an "OK"
button open it again and click the "OK" button

These tests should simply make sure there are no crashes by
opening/closing the dialogues and protect against regressions like
https://bugs.documentfoundation.org/show_bug.cgi?id=120227
https://bugs.documentfoundation.org/show_bug.cgi?id=125982
https://bugs.documentfoundation.org/show_bug.cgi?id=125985

I just wanted to have some feedback if picking those low-hanging
fruits is a valid approach and worth the effort and CI time.



I think that in general it is a good idea. Depending on how long it 
takes to execute the test we might need to think about whether we can 
actually include the tests in a normal make/make check or if they need 
to be treated differently. Did you already have a chat with Raal who 
has been writing tests for many bugs/dialogs already?



If yes I could extend the tests by:

 1. doing the same for writer, impress, etc.
 2. delete obsolete tests like uitest/calc_tests/about_test.py
 3. define preconditions for the "OK" click, e.g. input data into
fields
 4. define assertion after the click on the "OK" button



In general this sounds like a good idea. As mentioned it might be good 
to have a chat with Raal who might have an overview how far we are in 
opening all dialogs already.


Regards,
Markus


Thoughts? Ideas?

-- 
Artur Neumann

Director/CTO
Jankari Tech Pvt Ltd
www.jankaritech.com  
Phone: +977 9806639223
Skype: artur.n.
GitHub:https://github.com/individual-it

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org  

https://lists.freedesktop.org/mailman/listinfo/libreoffice


-- 
Artur Neumann

Director/CTO
Jankari Tech Pvt Ltd
www.jankaritech.com  
Phone: +977 9806639223
Skype: artur.n.
GitHub:https://github.com/individual-it

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org

https://lists.freedesktop.org/mailman/listinfo/libreoffice




--
LibreOffice is powered by a team of volunteers who mostly give their time for 
free.
We invite you to join as there are many ways to get involved including bugs 
triage,
marketing, UX, documentation, and of course developing -  
https://www.libreoffice.org/get-involved/

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: UI tests opening all possible dialogs

2019-06-22 Thread Markus Mohrhard 
Hello Artur,

On Fri, Jun 21, 2019 at 12:06 PM Artur Neumann 
wrote:

> Forgot the link to the changes, here it is:
> https://gerrit.libreoffice.org/#/c/74333/
> On 2019-06-20 5:01 p.m., Artur Neumann wrote:
>
> I've made some UI tests that open every dialog in calc, close it with the
> "close" or "cancel" button and if there is an "OK" button open it again and
> click the "OK" button
>
> These tests should simply make sure there are no crashes by
> opening/closing the dialogues and protect against regressions like
> https://bugs.documentfoundation.org/show_bug.cgi?id=120227
> https://bugs.documentfoundation.org/show_bug.cgi?id=125982
> https://bugs.documentfoundation.org/show_bug.cgi?id=125985
>
> I just wanted to have some feedback if picking those low-hanging fruits is
> a valid approach and worth the effort and CI time.
>
>
I think that in general it is a good idea. Depending on how long it takes
to execute the test we might need to think about whether we can actually
include the tests in a normal make/make check or if they need to be treated
differently. Did you already have a chat with Raal who has been writing
tests for many bugs/dialogs already?

If yes I could extend the tests by:
>
>1. doing the same for writer, impress, etc.
>2. delete obsolete tests like uitest/calc_tests/about_test.py
>3. define preconditions for the "OK" click, e.g. input data into fields
>4. define assertion after the click on the "OK" button
>
>
In general this sounds like a good idea. As mentioned it might be good to
have a chat with Raal who might have an overview how far we are in opening
all dialogs already.

Regards,
Markus

>
>
> Thoughts? Ideas?
>
> --
> Artur Neumann
> Director/CTO
> Jankari Tech Pvt Ltdwww.jankaritech.com
> Phone: +977 9806639223
> Skype: artur.n.
> GitHub: https://github.com/individual-it
>
>
> ___
> LibreOffice mailing 
> listLibreOffice@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/libreoffice
>
> --
> Artur Neumann
> Director/CTO
> Jankari Tech Pvt Ltdwww.jankaritech.com
> Phone: +977 9806639223
> Skype: artur.n.
> GitHub: https://github.com/individual-it
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: UI tests opening all possible dialogs

2019-06-20 Thread Artur Neumann 
Forgot the link to the changes, here it is:
https://gerrit.libreoffice.org/#/c/74333/

On 2019-06-20 5:01 p.m., Artur Neumann wrote:
>
> I've made some UI tests that open every dialog in calc, close it with
> the "close" or "cancel" button and if there is an "OK" button open it
> again and click the "OK" button
>
> These tests should simply make sure there are no crashes by
> opening/closing the dialogues and protect against regressions like
> https://bugs.documentfoundation.org/show_bug.cgi?id=120227
> https://bugs.documentfoundation.org/show_bug.cgi?id=125982
> https://bugs.documentfoundation.org/show_bug.cgi?id=125985
>
> I just wanted to have some feedback if picking those low-hanging
> fruits is a valid approach and worth the effort and CI time.
>
> If yes I could extend the tests by:
>
>  1. doing the same for writer, impress, etc.
>  2. delete obsolete tests like uitest/calc_tests/about_test.py
>  3. define preconditions for the "OK" click, e.g. input data into fields
>  4. define assertion after the click on the "OK" button
>
> Thoughts? Ideas?
>
> -- 
> Artur Neumann
> Director/CTO
> Jankari Tech Pvt Ltd
> www.jankaritech.com
> Phone: +977 9806639223
> Skype: artur.n.
> GitHub: https://github.com/individual-it
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

-- 
Artur Neumann
Director/CTO
Jankari Tech Pvt Ltd
www.jankaritech.com
Phone: +977 9806639223
Skype: artur.n.
GitHub: https://github.com/individual-it

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

UI tests opening all possible dialogs

2019-06-20 Thread Artur Neumann 
I've made some UI tests that open every dialog in calc, close it with
the "close" or "cancel" button and if there is an "OK" button open it
again and click the "OK" button

These tests should simply make sure there are no crashes by
opening/closing the dialogues and protect against regressions like
https://bugs.documentfoundation.org/show_bug.cgi?id=120227
https://bugs.documentfoundation.org/show_bug.cgi?id=125982
https://bugs.documentfoundation.org/show_bug.cgi?id=125985

I just wanted to have some feedback if picking those low-hanging fruits
is a valid approach and worth the effort and CI time.

If yes I could extend the tests by:

 1. doing the same for writer, impress, etc.
 2. delete obsolete tests like uitest/calc_tests/about_test.py
 3. define preconditions for the "OK" click, e.g. input data into fields
 4. define assertion after the click on the "OK" button

Thoughts? Ideas?

-- 
Artur Neumann
Director/CTO
Jankari Tech Pvt Ltd
www.jankaritech.com
Phone: +977 9806639223
Skype: artur.n.
GitHub: https://github.com/individual-it

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice