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

[Lucas Meneghel Rodrigues]

Cleber, yes, I agree with the points raised there, design-wise. I also like
the proposal of having best practices for modular/extensible parts of the
design.

On Tue, Sep 1, 2015 at 12:31 PM Cleber Rosa <crosa at redhat.com> wrote:

> 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.
>
> _______________________________________________
> Avocado-devel mailing list
> Avocado-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/avocado-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20150901/8abffe85/attachment.htm>