[Avocado-devel] [RFC] Plugins and Interfaces (using avocado.core.output.View as example)

[Cleber Rosa]

Hi folks,

I've been doing some research and prototyping these last days, and I
reached one specific point that I'd like to discuss early and openly.

The point is about the Avocado UI, and how we have pretended that
`avocado.core.output.View` follows some interface and could allow us
to switch one View (or UI) for another one. I reckon that, by not
having swappable Views (UIs), our design can be (actually is) broken.

So the proposals here are:

1) We should document, and maybe enforce, the interface that different
   components in Avocado expect and provide.

By documenting, it could be as simple as:

   # avocado/core/ui.py
   class Base(object):
       def setup(self):
           raise NotImplementedError
    def notify(self, event, msg='', **kwargs):
           raise NotImplementedError
    def teardown(self):
           raise NotImplementedError

Or we could enforce the implementation of these interfaces by using
Abstract Base Classes:

   # avocado/core/ui.py
   import abc
   class Base(object):
       __metaclass__ = abc.ABCMeta

        @abc.abstractmethod
        def setup(self):

        @abc.abstractmethod
        def notify(self, event, msg='', **kwargs):

        @abc.abstractmethod
        def teardown(self):

2) Having these interfaces defined, there should be at least two solid
   implementations that are tested in unittests and functional tests.

   class Silent(Base):
      def setup(self):
          pass

      def notify(self, event, msg='', **kwargs):
          pass

      def teardown(self):
          pass

    ---

    class Curses(Base):
       def setup(self):
           import curses
           window = curses.initscr()

       def notify(self, event, msg='', **kwargs):
           self.window.insstr(msg)

       def teardown(self):
           curses.endwin()

The point is that a `--silent` option SHOULD be implemented by
swapping the current UI "driver", and nothing else.

The UI example given here is not a big deal code-wise or even
functionality wise, but the same mentality and design should be taken
to other areas. Running a test remotely or on a container or on a
cloud instance should be a matter of swapping "test execution drivers"
and that's all.

My idea, given positive feedback, is to improve the current state of
things in the UI layer first, and make guidelines/best practices for
the other areas that should modular and extensible in Avocado.

Cheers,
Cleber Rosa.