QA (public) » openQA Project (public) » openQA Tests (public) » qe-yam

The current version of ui-framework-documentation.md reflects the way we were doing things last year: we were using external test data wherever we could to pass variables to the tests. Now, we try instead to use simple and specific modules for each specific situation, instead of complex modules that can be used in different situations, but are more complex. We could include a paragraph in the doc to explain the pros and cons of the different approaches:

• Complex modules with a lot of if-else conditions (the most ancient way, to be avoided).
• Variables passed from yaml schedules (test data) more simple but still complex, a compromise to have modules that can work in various cases and avoid spaghetti code.
• Very simple modules doing only one specific task, with schedules adapted for each case. Variables (test data) are passed from the test module to some libraries if needed. The name of the module reflects exactly what it does and the schedule is used to deal with the various situations instead of conditions in the code.

AC1: Include a new paragraph in ui-framework-documentation.md to explain pros and cons of older vs newer approach.
AC2: If logic requires it, update the parts of the doc about external test data.

Historical background: the first approch existed before we implement yaml scheduling: test suites were defined by two gigantic scripts that are still used in some cases, main.pm and main_common.pm. Second approach came with yaml schedule, as a compromise to avoid code repetition, get rid of main.pm and avoid spaghetti-code, in times when we were testing pretty different products in parallel (Sle 12 and 15, TW, leap). Then we realized this was making the test suites not so readable, and that the schedule could be used to deal with the various situations.