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:

perl refactoring designpatterns

This project is part of:

Hack Week 19

Activity

  • about 4 years ago: ybonatakis added keyword "perl" to this project.
  • about 4 years ago: ybonatakis added keyword "refactoring" to this project.
  • about 4 years ago: ybonatakis added keyword "designpatterns" to this project.
  • about 4 years ago: okurz liked this project.
  • about 4 years ago: bmwiedemann liked this project.
  • about 4 years ago: MDoucha liked this project.
  • about 4 years ago: SLindoMansilla liked this project.
  • about 4 years ago: ybonatakis started this project.
  • about 4 years ago: ybonatakis originated this project.

  • Comments

    • bmwiedemann
      about 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.

    • bmwiedemann
      about 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.

    • ybonatakis
      about 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.

    • okurz
      about 4 years ago by okurz | Reply

      @bmwiedemann Great to see you mention the original idea which I think is still valid but of course still has the caveats you presented :)

    • ybonatakis
      about 4 years ago by ybonatakis | Reply

      Propably not the right place to put it but i uploaded a small presentation Hackweek19pdf

    • ybonatakis
      about 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

    Grab precise changes in log file/s between system events by smhalas

    [comment]: # (Please use the project descriptio...


    opensuse-redir-cache by bmwiedemann

    [comment]: # (Please use the project descriptio...