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

  • 3 months ago: ybonatakis added keyword "perl" to Design patterns for os-autoinst-distri-opensuse
  • 3 months ago: ybonatakis added keyword "refactoring" to Design patterns for os-autoinst-distri-opensuse
  • 3 months ago: ybonatakis added keyword "designpatterns" to Design patterns for os-autoinst-distri-opensuse
  • 3 months ago: okurz liked Design patterns for os-autoinst-distri-opensuse
  • 3 months ago: bmwiedemann liked Design patterns for os-autoinst-distri-opensuse
  • 4 months ago: MDoucha liked Design patterns for os-autoinst-distri-opensuse
  • 4 months ago: SLindoMansilla liked Design patterns for os-autoinst-distri-opensuse
  • 4 months ago: ybonatakis started Design patterns for os-autoinst-distri-opensuse
  • 4 months ago: ybonatakis originated Design patterns for os-autoinst-distri-opensuse

  • Comments

    • bmwiedemann
      3 months 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
      3 months 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
      3 months 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
      3 months 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
      3 months ago by ybonatakis | Reply

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

    • ybonatakis
      3 months 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!