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

  • over 1 year ago: ybonatakis added keyword "perl" to this project.
  • over 1 year ago: ybonatakis added keyword "refactoring" to this project.
  • over 1 year ago: ybonatakis added keyword "designpatterns" to this project.
  • over 1 year ago: okurz liked this project.
  • over 1 year ago: bmwiedemann liked this project.
  • over 1 year ago: MDoucha liked this project.
  • over 1 year ago: SLindoMansilla liked this project.
  • over 1 year ago: ybonatakis started this project.
  • over 1 year ago: ybonatakis originated this project.

  • Comments

    • bmwiedemann
      over 1 year 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
      over 1 year 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
      over 1 year 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
      over 1 year 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
      over 1 year ago by ybonatakis | Reply

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

    • ybonatakis
      over 1 year 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

    Playwright for openQA by kraih

    Project Description

    This Hack Week i want...


    Dochazka by smithfarm

    Dochazka is a long-term project to replace the ...