coordination #15132
Updated by okurz over 6 years ago
## motivation
Currently the structure of the test plan in `main.pm` file is using simple if/else and variables which are mainly boolean to define the test plans for different scenarios with the help of some grouping functions. While there are problems advantages of this approach are that we are using simple tools and there is nearly no duplication of test module calls.
### problems
* **P1**: The test plan for individual scenarios is hard to follow and it is especially hard for new contributors of individual test modules to find a good place where a test module should be stored
* **P2**: It is hard to find out under which scenarios a certain test module is called
* **P3**: There is no easy way to add a module based on conditions but only based on existing scenarios which cover these conditions
* **P4**: There is no explicit place where to define the variables. The variables are mainly defined by name and use only.
* **P5**: Too much business logic is in the database settings which is not versioned in sync with the test code
* **P5.1**: The `templates` files are old and therefore confusing to some. As they are flattened database dumps they are not useful for manual editing
## suggestions
* **S1**: Better use `basetest::is_applicable` from os-autoinst in test modules with multiple inheritance and based on mixin patterns for modules
* **S2**: Use proper inheritance for variable definitions that influence the test plan, e.g. with perl hashes mapping to JSON objects. ('ENCRYPT_ACTIVATE_EXISTING' is a good example as it should basically be below the top level folder switch 'ENCRYPT' so that we can use it like `$vars{ENCRYPT}{ACTIVATE_EXISTING}`)
* **S3**: Define the flow of scenarios in a more concise way top-down with appropriate language
* **S3.1**: Use [dot language](http://www.graphviz.org/content/dot-language) or similar tools to describe the test plan as graphs and then use some automagic to encode that into the more verbose real test plan
* **S3.2**: Come up with a language proposal based on YAML