<div dir="ltr">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.<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 1, 2015 at 12:31 PM Cleber Rosa <<a href="mailto:crosa@redhat.com">crosa@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<br>
<br>
I've been doing some research and prototyping these last days, and I<br>
reached one specific point that I'd like to discuss early and openly.<br>
<br>
The point is about the Avocado UI, and how we have pretended that<br>
`avocado.core.output.View` follows some interface and could allow us<br>
to switch one View (or UI) for another one. I reckon that, by not<br>
having swappable Views (UIs), our design can be (actually is) broken.<br>
<br>
So the proposals here are:<br>
<br>
1) We should document, and maybe enforce, the interface that different<br>
components in Avocado expect and provide.<br>
<br>
By documenting, it could be as simple as:<br>
<br>
# avocado/core/ui.py<br>
class Base(object):<br>
def setup(self):<br>
raise NotImplementedError<br>
def notify(self, event, msg='', **kwargs):<br>
raise NotImplementedError<br>
def teardown(self):<br>
raise NotImplementedError<br>
<br>
Or we could enforce the implementation of these interfaces by using<br>
Abstract Base Classes:<br>
<br>
# avocado/core/ui.py<br>
import abc<br>
class Base(object):<br>
__metaclass__ = abc.ABCMeta<br>
<br>
@abc.abstractmethod<br>
def setup(self):<br>
<br>
@abc.abstractmethod<br>
def notify(self, event, msg='', **kwargs):<br>
<br>
@abc.abstractmethod<br>
def teardown(self):<br>
<br>
2) Having these interfaces defined, there should be at least two solid<br>
implementations that are tested in unittests and functional tests.<br>
<br>
class Silent(Base):<br>
def setup(self):<br>
pass<br>
<br>
def notify(self, event, msg='', **kwargs):<br>
pass<br>
<br>
def teardown(self):<br>
pass<br>
<br>
---<br>
<br>
class Curses(Base):<br>
def setup(self):<br>
import curses<br>
window = curses.initscr()<br>
<br>
def notify(self, event, msg='', **kwargs):<br>
self.window.insstr(msg)<br>
<br>
def teardown(self):<br>
curses.endwin()<br>
<br>
The point is that a `--silent` option SHOULD be implemented by<br>
swapping the current UI "driver", and nothing else.<br>
<br>
The UI example given here is not a big deal code-wise or even<br>
functionality wise, but the same mentality and design should be taken<br>
to other areas. Running a test remotely or on a container or on a<br>
cloud instance should be a matter of swapping "test execution drivers"<br>
and that's all.<br>
<br>
My idea, given positive feedback, is to improve the current state of<br>
things in the UI layer first, and make guidelines/best practices for<br>
the other areas that should modular and extensible in Avocado.<br>
<br>
Cheers,<br>
Cleber Rosa.<br>
<br>
_______________________________________________<br>
Avocado-devel mailing list<br>
<a href="mailto:Avocado-devel@redhat.com" target="_blank">Avocado-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/avocado-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/avocado-devel</a><br>
</blockquote></div>