action #69184
closed
coordination #36712: [saga] Use YaST specific framework for GUI testing
[y][timeboxed:24h] Design architecture for ruby rspec yast tests
Added by riafarov almost 4 years ago.
Updated over 3 years ago.
Target version:
SUSE QA - SLE 15 SP3
Description
We continue progressing to reduce maintenance costs of screen-based testing.
After making decisions how we are going to launch tests, we can design architecture for the tests them self, which match outcome of #68983
We have multiple versions of multiple distributions.
Options are:
a) Store with yast module code
b) Store it in os-autoinst-distri-opensuse repo
c) Create separate repo to store test code
Challenges:
- Where to store tests?
- Skeleton for the test framework (MVC ?)
As we target expert partitioner as a first module, we can use it for this research and write some simple test for it.
- Subject changed from [y] Design architecture for ruby rspec yast tests to [y][timeboxed:24h] Design architecture for ruby rspec yast tests
- Description updated (diff)
- Status changed from New to Workable
- Assignee set to JERiveraMoya
- Due date changed from 2020-08-11 to 2020-08-25
- Status changed from Workable to In Progress
- Status changed from In Progress to Feedback
- Organization created (I added team members to it and the new project)
- PoC: https://github.com/qa-sle-yast/libyui_test_framework
For launching the YaST modules, we will run from openQA su -c /bin/sh and type the password once (unavoidable AFIK) and then we will run bundle exec rspec. The way to open the module was unified, check the spec although the code perhaps makes more sense to be in the framework instead of the client.
For output validation we could use Open3
Note 1: Ensure loading of the screen is still an issue to be solved when developing the framework, for example in Expert Partitioner in SLE is not enough to wait for the tree to send a selection on the tree, because if the central pane is not loaded, the screen got frozen, not usable, I workarounded that waiting for the central screen, but it does not work fine stable with TW, so it might be require more element to be waited for.
Note 2: I didn't see any issues with port after applying the env variable to reuse the port.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF