action #106936
Updated by JRivrain about 2 years ago
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. could, sometimes in a rather dogmatic way. Now, we try to avoid using test data at all when possible, and 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. a "strict-expectations" approach. We could include a paragraph in the doc to explain the pros and cons of the two different approaches: approaches (eg "External data, or fixed expectation ?") - Complex modules with a lot of conditions (the most ancient way, to be avoided). - Variables passed from yaml schedules (test data) With strict expectations, tests suites are more simple but still complex, a compromise readable, it seems to have modules that can work in various cases and avoid spaghetti code. - Very simple modules doing only advantages. However, this might become more complex when we will deal with more than one specific task, product, which is why we came up with schedules adapted for each case, variables (test data) are passed from the idea of external test module to some libraries if needed. The name of the module reflects exactly what it does data : avoid conditions and code duplication. With the schedule strict-expectation approach, the risk is used to deal end-up with 10 modules that are almost identical except for... test data. So we could try to imagine what will happen when a new product will arrive, with small (SP5) or big (sle 16) differences, and document the various situations instead recommendations that we will come up with. For example, we have the idea of conditions in the code. inherited yaml schedules (https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/14241) AC1: Include a new paragraph in ui-framework-documentation.md to explain pros and cons of older external test data vs newer approach. strict expectations. 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 Consider a compromise model to avoid code repetition, get rid of main.pm integrate upcoming products, and avoid spaghetti-code, in times when we were testing pretty different working with various products in parallel (Sle 12 at once (eg sle 16 and 15, TW, leap). Then we realized this was making sle 15 sp5). AC3: After discussion with the test suites not so readable, and that team, include the schedule could be used to deal with new ideas from AC2 in the various situations. doc.