action #56786


coordination #36712: [saga] Use YaST specific framework for GUI testing

coordination #50672: [funtional][y][epic] Use libyui-rest-api for YaST modules testing

[functional][y] Improve ruby gem library to operate controls in the UI

Added by JERiveraMoya over 4 years ago. Updated over 3 years ago.

Target version:
SUSE QA - Milestone 28
Start date:
Due date:
% Done:


Estimated time:
13.00 h



I as a YaST developer want to write integration tests for the module

Based on the code implemented by Ladi:, after #56009 we already have a gem able to operate a few controls in the UI:

Ladi provides with 3 suggestions. See (1)(2)(3) below.
We should also (4) format the code and (5) extend the library trying with other users controls.

1) the "it" describes a single test, each test should be independent (i.e. do not
depend on the result of any previous test). RSpec even supports randomizing the order
of the tests using the "rspec --order random" option, this can help to find the
dependencies between the tests.

Moreover rspec can optionally run only a specified test, not the whole file. Example:
"rspec spec/libyui_client_spec.rb:38", that will start the test at line 38, ignoring
the other tests.

So there should be one big: it "writes the entered IP address to the /etc/hosts" do ...

test which does all the steps inside.

We need to print the progress messages by yourselves,
We might use "rainbow" gem or similar to print the colored output (or maybe rspec provides some API)

2) The test is destructive, it really modifies the /etc/hosts on the machine.
That's OK when running it in a testing environment (like openQA) but it's not
acceptable if you want to run the same test on your machine during development.

Ideally there should be a way to run the read-only and the read/write tests
separately. E.g. the read-only tests would simply press "Abort" button in the
end to avoid writing the changes to the system.

Or we could pass the read/write mode via the environment and depending on that the
"write" part would be skipped or not, that would avoid duplicating the tests.

We definitely need a way to safely run the tests (at least some safe subset) during the development.

3) Use the "aruba" gem for testing the file content, file existence,
file permissions, command STDOUT or STDERR, etc...

We do not need to reinvent the wheel in

So far Lady has used aruba only from cucumber tests, but it seems it provides some
helpers also for rspec.


Or maybe there is some other rspec extension for that, but as this is a really common problem,
some library (gem) must already exist...

4) Format the code with rubocop.
5) Extend the library interacting with other controls.

Acceptance criteria

  1. Code is formatted with robocop
  2. Checkbox, radiobuttons, textbox, table basic interaction (set/get) is implemented in the library


Check if can serialize objects from the json which libyui-restapi sends, as to apply MVC in the end.


DEBUG_libyui_client.txt (5.91 KB) DEBUG_libyui_client.txt rspec output with DEBUG=1 JERiveraMoya, 2019-09-24 07:32
libyui_client.png (108 KB) libyui_client.png rspec output JERiveraMoya, 2019-09-24 07:32
Actions #1

Updated by riafarov over 4 years ago

  • Description updated (diff)
  • Status changed from New to Workable
  • Estimated time set to 13.00 h
Actions #2

Updated by JERiveraMoya over 4 years ago

  • Assignee set to JERiveraMoya
Actions #3

Updated by JERiveraMoya over 4 years ago

  • Status changed from Workable to In Progress
Actions #4

Updated by riafarov over 4 years ago

  • Target version set to Milestone 28
Actions #6

Updated by JERiveraMoya over 4 years ago

  • Status changed from Feedback to Resolved

Serialization is already done in JSON object, I evaluated OpenStruct instead of JSON object but the performance seems to be worse (it is basically an object that you can access with dot (.) to all properties, but it is not good for encapsulation so I went for creating our own object and the way to call the fields does not matter if it is with dot or with ["field"].
1) done
2) not done
3) not done
4) done (although it still showing multiple minor warnings, for example length of lines)
5) done

As we agreed 2) and 3) did not have so much priority for us atm and we need to focus on the library. Created follow-up ticket:


Also available in: Atom PDF