The idea is to hack os-autoinst-distri-opensuse infrastucture and explore design patterns that can fit. The end point of this is to restructure the framework in such a way that the main-common.pm is more efficient, functional and readable.
Looking for hackers with the skills:
This project is part of:
Hack Week 19
Activity
Comments
-
over 4 years ago by bmwiedemann | Reply
For the record, my original design can still be seen in https://github.com/os-autoinst/os-autoinst/tree/v1/consoletest.d
There, test modules would be evaluated in order and their is_applicable method would decide if it needs to run in the current scenario.
That also had downsides: it was hard to skip a larger number of modules, so to help there, there were base classes like https://github.com/os-autoinst/os-autoinst/blob/v1/autoinstallstep.pm that implemented is_applicable for all their subclasses. A bit better, but still not really nice.
-
over 4 years ago by bmwiedemann | Reply
But on the plus side, you could just symlink a new test module into a directory and it would run as part of the next sequence. And any syntax error in a module would just cause this one module to be skipped.
-
over 4 years ago by ybonatakis | Reply
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/9545 So far the design seems to work for a single test suite. I am trying to add more and test them. Also i need to move the factory classes out of the main.pm.
-
over 4 years ago by ybonatakis | Reply
Propably not the right place to put it but i uploaded a small presentation Hackweek19pdf
-
over 4 years ago by ybonatakis | Reply
Final update of the status of the project. The factory design pattern has been applied. The Factory class is able to pick the correct subclass of the TestSuiteInterface.pm (which all the test suites should inherit from). The main.pm has only to initialize the factory and ask from the whatever test to run the proper scheduler for the ongoing test suite. A following up development should expand (adding the abstraction for) the design to add the modules of each test suite based on other factors, like ARCH.
Similar Projects
This project is one of its kind!