Posts

Showing posts from August, 2019

GSoC final report

Image
Overview The idea of this GSoC project was to implement new Domain-Specific language for LibreOffice to be used in UI testing by logging the user interactions with LO applications then generate the python code needed for the python UI framework which asaswill make testing easier. Also, the project aims to improve the logger that logs all the user interaction to be logged in the new DSL syntax to be more readable. Then we can use this replaying all the user interactions as a UI test.
Achievements Grammar of new DSL done forstarter_commandsuno_commandsdialog_commands General_commandsGrammar that are general for all application.
UI_Object_commands This support:ButtonUIObject EditUIObject CheckBoxUIObjectRadioButtonUIObject ListBoxUIObject  ComboBoxUIObject SpinUIObject TabControlUIObject Special_commandsThis is for the logging of different applications actions:
Writer
TypeSelectGOTO pageCalc
Type Select cell or rangelaunch AutoFill ImpressTypeMath
element selector Type Rewrite all the logging…

UI Logger

This post is just documentation for GSoC Project of UI logger here:
https://summerofcode.withgoogle.com/projects/#5252265672179712

This project is to generate a new easier Domain-Specific_language for logging the user interactions to be able to convert it to a python script that used by python UI framework for testing.

This project made with Textx which is a meta-language for building Domain-Specific Languages (DSLs) in Python. it helps you build your textual language in an easy way. You can invent your own language or build support for already existing textual language or file format.

If you need to understand how the project is written and mainly the part in this folder: https://opengrok.libreoffice.org/xref/core/uitest/ui_logger_dsl/ I think you can easily see the tutorials here of TextX. The basics of this tutorial that you can understand with 30 mins can let you understand a lot of the project.

WHY DSL?
DSL is a very useful thing because it lets us understand the code without you ha…

Week 12 Report

This week:

1) It was The last week of GSoC program. Raal was working on testing all the project and the generated files and I help him by solving some bugs or add anything.
add the SideBar implementation:
their was no implementation for the sidebar commands to be converted to uitest so here I added the implementation of it:
https://gerrit.libreoffice.org/#/c/77653/Ignore the logging part of the QuerySaveDialog while closing the app:
as it is not important for a uitest to make in every test simulation of asking the user for saving the document or not. This can be found here:
https://gerrit.libreoffice.org/#/c/77615/Use prefix for names that has conflict with python's words:
avoid using a reserved work of the python words to avoid making variable that name is 'if' or any of these words. This can be found here:
https://gerrit.libreoffice.org/#/c/77557/Replace tabs with spaces:
as LO uses spaces . This can be found here:
https://gerrit.libreoffice.org/#/c/77539/ Add footer line:
https:/…

Week 11 Report

Image
This week:

1) I have worked in solving the problem of un-named parent :
For example, if I open calc and select any cell you will find a field in the upper tab that has the name of the cell for example C10. If I tried to type another name in this I will get this log statement:
>>Type on 'pos_window' {"TEXT": "a"} from
This means that the 'pos_window' edit UI object has a parent with no name. So how to solve it and how to generate a UI test Case that corresponds to this action as I know I should convert it to something like this:

pos_window = [Parent_Name].getChild("pos_window")
pos_window.executeAction("TYPE", mkPropertyValues({"TEXT": "a"}))

This problem happens in many unexpected places and it makes the compiler stuck in running and not convert the logger to a UI test.

The easiest fix is to change the logger to recursively query the parent until you find an element with a name. Usually, that should work…

Week 10 Report

This week:

1) I tried to work on the Some draw and Impress to log more events on them but the problem was that they were having the same function that they call to perform similar operations.

To Solve This for example for the:
Add_Slide    ====> in impressAdd_page    ====> in draw I add these events to the logger in this Commit:
https://gerrit.libreoffice.org/#/c/76889/ So now we have these log Statements for examples:
Insert new Slide at position 3   ====> in impressInsert new Page at position 3   ====> in draw2) In the Same Commit (this one) I make a modification in the UITestLogger class to be able to know the difference between the draw and the Impress log statements and be able to store the current working app information.

3) Also add some new events to be supported with our UI logger like:
 ImpressInsert SlideDelete SideDuplicate Slide Rename SlideDrawInsert PageDelete PageRename PageThis Work Can be found here:
https://gerrit.libreoffice.org/#/c/76895/
4) Log More Events: