qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Cleber Rosa <crosa@redhat.com>
Cc: "Stefan Hajnoczi" <stefanha@redhat.com>,
	qemu-devel@nongnu.org, "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Fam Zheng" <famz@redhat.com>, "Amador Pahim" <amador@pahim.org>
Subject: Re: [Qemu-devel] [PATCH v3 3/5] Acceptance tests: add quick VNC tests
Date: Wed, 30 May 2018 17:00:32 -0300	[thread overview]
Message-ID: <20180530200032.GF7451@localhost.localdomain> (raw)
In-Reply-To: <47189c37-afec-6366-e9e4-cae5999d9eb2@redhat.com>

On Wed, May 30, 2018 at 02:00:48PM -0400, Cleber Rosa wrote:
> 
> 
> On 05/30/2018 12:29 PM, Eduardo Habkost wrote:
> > On Wed, May 30, 2018 at 01:57:05PM +0100, Stefan Hajnoczi wrote:
> >> On Tue, May 29, 2018 at 03:37:28PM -0400, Cleber Rosa wrote:
> >>> This patch adds a few simple behavior tests for VNC.
> >>>
> >>> Signed-off-by: Cleber Rosa <crosa@redhat.com>
> >>> ---
> >>>  tests/acceptance/vnc.py | 60 +++++++++++++++++++++++++++++++++++++++++
> >>>  1 file changed, 60 insertions(+)
> >>>  create mode 100644 tests/acceptance/vnc.py
> >>>
> >>> diff --git a/tests/acceptance/vnc.py b/tests/acceptance/vnc.py
> >>> new file mode 100644
> >>> index 0000000000..b1ef9d71b1
> >>> --- /dev/null
> >>> +++ b/tests/acceptance/vnc.py
> >>> @@ -0,0 +1,60 @@
> >>> +# Simple functional tests for VNC functionality
> >>> +#
> >>> +# Copyright (c) 2018 Red Hat, Inc.
> >>> +#
> >>> +# Author:
> >>> +#  Cleber Rosa <crosa@redhat.com>
> >>> +#
> >>> +# This work is licensed under the terms of the GNU GPL, version 2 or
> >>> +# later.  See the COPYING file in the top-level directory.
> >>> +
> >>> +from avocado_qemu import Test
> >>> +
> >>> +
> >>> +class Vnc(Test):
> >>> +    """
> >>> +    :avocado: enable
> >>> +    :avocado: tags=vnc,quick
> >>> +    """
> >>> +    def test_no_vnc(self):
> >>> +        self.vm.add_args('-nodefaults', '-S')
> >>> +        self.vm.launch()
> >>
> >> If this pattern becomes very common maybe vm.launch() should become
> >> vm.launch(*extra_args) to make this a one-liner:
> >>
> >>   self.vm.launch('-nodefaults', '-S')
> > 
> > I think this was suggested in the past:
> > 
> >   self.vm.add_args(...).launch()
> > 
> > This style would be useful if we add other methods that change
> > QEMU options in addition to raw add_args().  e.g.:
> > 
> >   self.vm.add_args(...).add_console(...).add_drive(...).launch()
> > 
> 
> Yes, this is an old discussion indeed.  IMO, method chaining can look
> attractive at first, but it will quickly bring a few new issues to be
> dealt with.

Which new issues?  I don't see any below.

> 
> For once, it brings the assumption that it can be done for all methods.
>  Using the previous example I'd expect to be able to do:
> 
>    self.vm.add_args(...).launch(...).migrate(...).shutdown()
> 
> Which seems fine, but now the code is plagued with "return self" statements.

Why the "return self" would be a problem?


> 
> Then, code style and indentation questions will quickly arise.  Either this:
> 
>    self.vm.add_args('-nodefaults', '-S').add_console('isa-serial') \
>           .add_drive(file='/path/to/file, format='raw').launch() \
>           .shutdown()

Maybe it's a matter of personal taste, but I don't see a problem
with this:

    self.vm.add_args('-nodefaults', '-S') \
        .add_console('isa-serial') \
        .add_drive(file='/path/to/file, format='raw') \
        .launch() \
        .shutdown()

> 
> Or this:
> 
>    (self.vm.add_args('-nodefaults', '-S').add_console('isa-serial')
>            .add_drive(file='/path/to/file, format='raw').launch()
>            .shutdown())

If you end up with very complex chains like above, you are still
free to split it into multiple statements.

I don't see why this would be an argument against making this
possible:

  self.vm.add_args('-nodefaults', '-S').launch()


> 
> Looks just as bad to me.  The non-method chaining syntax would look like:
> 
>    self.vm.add_args('-nodefaults', '-S')
>    self.vm.add_console('isa-serial')
>    self.vm.add_drive(file='/path/to/file, format='raw')
>    self.vm.launch()
>    self.vm.shutdown()

This is reasonable style if the .add_*() calls don't fit on a
single line.


> 
> Or even:
> 
>    with self.vm as vm:
>       vm.add_args('-nodefaults', '-S')
>       vm.add_console('isa-serial')
>       vm.add_drive(file='/path/to/file, format='raw')
>       vm.launch()
>    # shutdown() called on __exit__()

I don't like the extra indentation level, but people are free to
use this style.

(BTW, I think avocado_qemu must call shutdown() automatically
instead of requiring test code to do it manually.)


> 
> Which IMO, are superior in readability and clarity.  This is a matter of
> choosing a style, so that we can expect (demand?) that tests follow it.

They are more readable than the complex method chaining examples
you have shown, but I don't see any argument against:

  self.vm.add_args(...).launch()


> 
> I'm certainly less experienced with the project dynamics than most here,
> so I'm strongly hoping for your input to quickly define the code style
> to be used here.
> 
> Because of that, I'll skip changing anything here on v4.

Agreed: I don't think any changes to the add_args() style need to
be on v4.  I'd prefer to work to include avocado_qemu first, and
later consider how we can improve the qemu.py and avocado_qemu.py
APIs.

-- 
Eduardo

  reply	other threads:[~2018-05-30 20:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-29 19:37 [Qemu-devel] [PATCH v3 0/5] Acceptance/functional tests Cleber Rosa
2018-05-29 19:37 ` [Qemu-devel] [PATCH v3 1/5] Add functional/acceptance tests infrastructure Cleber Rosa
2018-05-30 12:54   ` Stefan Hajnoczi
2018-05-30 18:15     ` Cleber Rosa
2018-05-29 19:37 ` [Qemu-devel] [PATCH v3 2/5] scripts/qemu.py: allow adding to the list of extra arguments Cleber Rosa
2018-05-30 12:54   ` Stefan Hajnoczi
2018-05-29 19:37 ` [Qemu-devel] [PATCH v3 3/5] Acceptance tests: add quick VNC tests Cleber Rosa
2018-05-30 12:57   ` Stefan Hajnoczi
2018-05-30 13:04     ` Fam Zheng
2018-05-30 16:29     ` Eduardo Habkost
2018-05-30 18:00       ` Cleber Rosa
2018-05-30 20:00         ` Eduardo Habkost [this message]
2018-05-30 21:03           ` Cleber Rosa
2018-05-30 21:31             ` Eduardo Habkost
2018-05-30 22:28               ` Cleber Rosa
2018-05-30 12:57   ` Stefan Hajnoczi
2018-05-29 19:37 ` [Qemu-devel] [PATCH v3 4/5] scripts/qemu.py: introduce set_console() method Cleber Rosa
2018-05-30 19:17   ` Stefan Hajnoczi
2018-05-29 19:37 ` [Qemu-devel] [PATCH v3 5/5] Acceptance tests: add Linux kernel boot and console checking test Cleber Rosa
2018-05-30 19:20   ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180530200032.GF7451@localhost.localdomain \
    --to=ehabkost@redhat.com \
    --cc=amador@pahim.org \
    --cc=crosa@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=famz@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).