UI tests opening all possible dialogs
artur at jankaritech.com
Mon Jun 24 07:22:21 UTC 2019
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.
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://bugs.documentfoundation.org/show_bug.cgi?id=123508>.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
> InsertObjectChart - lots of tests exists in directory
> FunctionDialog -
> 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 <https://bugs.documentfoundation.org/show_bug.cgi?id=125982>,
> 125985 <https://bugs.documentfoundation.org/show_bug.cgi?id=125985>)
> Best regards,
> On 22. 06. 19 11:10, Markus Mohrhard wrote:
>> Hello Artur,
>> On Fri, Jun 21, 2019 at 12:06 PM Artur Neumann <artur at jankaritech.com
>> <mailto:artur at jankaritech.com>> wrote:
>> Forgot the link to the changes, here it is:
>> 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
>>> 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.
>>> Thoughts? Ideas?
>>> Artur Neumann
>>> Jankari Tech Pvt Ltd
>>> www.jankaritech.com <http://www.jankaritech.com>
>>> Phone: +977 9806639223
>>> Skype: artur.n.
>>> GitHub: https://github.com/individual-it
>>> LibreOffice mailing list
>>> LibreOffice at lists.freedesktop.org <mailto:LibreOffice at lists.freedesktop.org>
>> Artur Neumann
>> Jankari Tech Pvt Ltd
>> www.jankaritech.com <http://www.jankaritech.com>
>> Phone: +977 9806639223
>> Skype: artur.n.
>> GitHub: https://github.com/individual-it
>> LibreOffice mailing list
>> LibreOffice at lists.freedesktop.org
>> <mailto:LibreOffice at lists.freedesktop.org>
> 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 at lists.freedesktop.org
Jankari Tech Pvt Ltd
Phone: +977 9806639223
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LibreOffice