On 10/3/18 10:27 AM, Ancor Gonzalez Sosa wrote:
On 10/02/2018 11:18 AM, Lukas Ocilka wrote:
-------- Forwarded Message --------
Subject: YaST GUI testing framework
Date: Mon, 24 Sep 2018 18:37:18 +0200
From: Rodion Iafarov <[email protected]>
To: [email protected]
Dear YaSTees,
I would like to kindly ask for your help. In order to make next game
changing step for YaST GUI testing, we need to improve macro player
functionality.
After a nice discussion with Stefan Hundhammer and Chistopher Hofmann,
we got clear that we cannot simply resurrect functionality which was
there already as it's based on YCP, which YaST team wants to replace for
quite a while. Our QA team feels fancy to help with the progress in
order to get scalable framework for YaST GUI testing, including
installer. However, as you have better insights, we need your help to
decide steps to be done and split them to the items we can deliver
during the sprint. This will allow us slowly moving forward.
Questions to clarify before we start:
1) Will YCP be dropped in foreseeable future, if yes what shall be used
instead? yaml+ruby?
Do you mean the programming language called YCP or the components system
called YCP?
I actually meant both, as my understanding was that Communication
Protocol is also a subject to change.
In general, it doesn't matter what will it be, my main motivation is to
find solution which fits all our needs.
I'm asking because, although we usually say "YCP" to refer to that
perl-ish language we are indeed dropping, YCP actually stands for YaST
Communication Protocol and I would say is still the main method to
communicate our Ruby code with libYUI and with WFM. Isn't it?
For more fun with acronyms, check
https://yastgithubio.readthedocs.io/en/latest/architecture/
2) Where to start? We could have a fork of libyui which is used for
testing, or our implementation has to be secure not to introduce any new
flaws
Using a separate "feature branch" sounds good as long as it does not run
for two years before being merged back to master, like storage-ng. :-)
In case we cannot get enough support and development is too heavy, we
may use squish or ldtp, which have certain limitations, but will server
the purpose.
Looking forward to your reply.
Cheers.
--
Kind regards,
Rodion Iafarov <[email protected]>
QA Engineer
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg
Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
