coordination #36712: [saga] Use YaST specific framework for GUI testing
[y][timeboxed:24h] Design architecture for ruby rspec yast tests
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.
a) Store with yast module code
b) Store it in os-autoinst-distri-opensuse repo
c) Create separate repo to store test code
- 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.
#2 Updated by JERiveraMoya over 1 year ago
In case it could help (as got confused myself with this), I think we are referring to Page-Object Model / Page-Object pattern instead of the MVC, so we are looking for the pattern(s) to use to create our Automation Framework. We can check: https://blog.testproject.io/2020/06/29/design-patterns-in-test-automation/
#6 Updated by JERiveraMoya over 1 year ago
- 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.