The avocado_qemu package provides the following methods to interact with the
guest via console, which are mainly used on the acceptance boot tests:

 exec_command(), exec_command_and_wait_for_pattern(), wait_for_console_pattern(),
 interrupt_interactive_console_until_pattern()

Those methods are loosely defined in avocado_qemu/__init__.py. Because that file is expected to
grow, I thought that for the sake of keeping it organized it would be better to logically group
them. So in this series I create the ConsoleMixIn class to be the new home for the console
methods. An alternative approach could be to create a separated package, however because
they are just a few methods at the moment, I prefered not to break avocado_qemu into smaller pieces.

As the "MixIn" in the name implies, the class is meant to be used as a mixin on the test class. Here
I am following an idea introduced by Cleber in [1].

This series was tested on CI (https://gitlab.com/wainersm/qemu/-/pipelines/296412039)

[1] http://next.patchew.org/QEMU/20210412044644.55083-1-crosa@redhat.com/

Wainer dos Santos Moschetta (7):
  tests/acceptance: Introduce the ConsoleMixIn class
  tests/acceptance: Move exec_command to ConsoleMixIn
  tests/acceptance: Move exec_command_and_wait_for_pattern to
    ConsoleMixIn
  tests/acceptance: Sun4uMachine: Remove dependency to LinuxKernelTest
  tests/acceptance: replay_kernel: Remove unused
    wait_for_console_pattern
  tests/acceptance: Move wait_for_console_pattern to ConsoleMixIn
  tests/acceptance: Move _console_interaction to ConsoleMixIn

 tests/acceptance/avocado_qemu/__init__.py    | 161 +++++++++----------
 tests/acceptance/boot_linux_console.py       | 133 ++++++++-------
 tests/acceptance/boot_xen.py                 |   5 +-
 tests/acceptance/linux_ssh_mips_malta.py     |   8 +-
 tests/acceptance/machine_arm_canona1100.py   |   6 +-
 tests/acceptance/machine_arm_integratorcp.py |   8 +-
 tests/acceptance/machine_arm_n8x0.py         |   6 +-
 tests/acceptance/machine_microblaze.py       |   8 +-
 tests/acceptance/machine_mips_loongson3v.py  |   6 +-
 tests/acceptance/machine_mips_malta.py       |   6 +-
 tests/acceptance/machine_ppc.py              |  10 +-
 tests/acceptance/machine_rx_gdbsim.py        |  15 +-
 tests/acceptance/machine_s390_ccw_virtio.py  |  79 +++++----
 tests/acceptance/machine_sparc64_sun4u.py    |  13 +-
 tests/acceptance/machine_sparc_leon3.py      |   8 +-
 tests/acceptance/multiprocess.py             |  14 +-
 tests/acceptance/ppc_prep_40p.py             |  16 +-
 tests/acceptance/replay_kernel.py            |   1 -
 tests/acceptance/virtio-gpu.py               |  16 +-
 tests/acceptance/virtiofs_submounts.py       |   1 -
 20 files changed, 249 insertions(+), 271 deletions(-)

-- 
2.29.2

Hi Wainer,

On Mon, May 3, 2021 at 7:43 PM Wainer dos Santos Moschetta
<wainersm@redhat.com> wrote:
>
> The avocado_qemu package provides the following methods to interact with the
> guest via console, which are mainly used on the acceptance boot tests:
>
>  exec_command(), exec_command_and_wait_for_pattern(), wait_for_console_pattern(),
>  interrupt_interactive_console_until_pattern()
>
> Those methods are loosely defined in avocado_qemu/__init__.py. Because that file is expected to
> grow, I thought that for the sake of keeping it organized it would be better to logically group
> them. So in this series I create the ConsoleMixIn class to be the new home for the console
> methods. An alternative approach could be to create a separated package, however because
> they are just a few methods at the moment, I prefered not to break avocado_qemu into smaller pieces.
>
> As the "MixIn" in the name implies, the class is meant to be used as a mixin on the test class. Here
> I am following an idea introduced by Cleber in [1].
>
> This series was tested on CI (https://gitlab.com/wainersm/qemu/-/pipelines/296412039)
>
> [1] http://next.patchew.org/QEMU/20210412044644.55083-1-crosa@redhat.com/
>

So, personally, I found this an interesting change, it keeps the code
more organized IMO.

I have mixed feelings about using mixin for something that should be
straightforward, like develop tests on a project where python is not
the primary programming language. I would imagine that the mixin
pattern is nice inside core code and functions or methods are more
suitable for test writers.

Anyway, I'm not against it and will not block the series if others are
okay with the changes.