Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Ed Bartosh <ed.bartosh@linux.intel.com>
To: Jair Gonzalez <jair.de.jesus.gonzalez.plascencia@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] selftest/wic: extending test coverage for WIC script options
Date: Wed, 14 Dec 2016 13:44:30 +0200	[thread overview]
Message-ID: <20161214114430.GA19511@linux.intel.com> (raw)
In-Reply-To: <012801d255a0$806ad8e0$81408aa0$@linux.intel.com>

On Tue, Dec 13, 2016 at 06:24:57PM -0600, Jair Gonzalez wrote:
> Hi Ed,
> 
> Thank you for your response and suggestions. Below are my comments.
> 

> > > +    @testcase(1557)
> > > +    def test_listed_images_help(self):
> > > +        """Test wic listed images help"""
> > > +        output = runCmd('wic list images').output
> > > +        imageDetails = [line.split() for line in output.split('\n')]
> > > +        imageList = [row[0] for row in imageDetails]
> > How about replacing two last lines with this?
> > imagelist = [line.split()[0] for line in output.split('\n')]
> I agree. What about this?
> imagelist = [line.split()[0] for line in output.splitlines()]

This is event better, thanks!

> > > +
> > > + "--image-name=core-image-minimal").status)
> > Is '=' mandatory here?
> On wic's help it appears as mandatory, but on practice, it can be used both
> ways. I decided to use both ways along the module to test both usages and
> increase coverage, but not to dedicate specific test cases to each
> combination.

Makes sense to me.

> > >      def test_compress_gzip(self):
> > >          """Test compressing an image with gzip"""
> > >          self.assertEqual(0, runCmd("wic create directdisk "
> > > -                                   "--image-name core-image-minimal "
> > > +                                   "-e core-image-minimal "
> > --image-name is more readable than -e from my point of view.
> Similarly to the '=' to define long option names' arguments, I used both
> forms of each option along the module to increase coverage.
OK

> > > +    def test_debug_skip_build_check_and_build_rootfs(self):
> > > +        """Test wic debug, skip-build-check and build_rootfs"""
> > > +        self.assertEqual(0, runCmd("wic create directdisk "
> > > +                                   "--image-name=core-image-minimal "
> > > +                                   "-D -s -f").status)
> > > +        self.assertEqual(1, len(glob(self.resultdir +
> "directdisk-*.direct")))
> > > +        self.assertEqual(0, runCmd("wic create directdisk "
> > > +                                   "--image-name=core-image-minimal "
> > > +                                   "--debug "
> > > +                                   "--skip-build-check "
> > > +                                   "--build-rootfs").status)
> > > +        self.assertEqual(1, len(glob(self.resultdir +
> > > + "directdisk-*.direct")))
> > > +
> > I'd split this to two test cases as they're testing two different options.
> Actually, those are three different options (with their short and long
> versions). I did this to not add too many test cases, but as you mention,
> probably it's better to separate them by option to make it clearer.
Agreed.

> core-image-minimal").status)
> > > -        self.assertEqual(1, len(glob(self.resultdir + "HYBRID_ISO_IMG-
> > *.direct")))
> > > -        self.assertEqual(1, len(glob(self.resultdir +
> "HYBRID_ISO_IMG-*.iso")))
> > > +                                   "--image-name core-image-minimal"
> > > +                                   ).status)
> > This is less readable. Is this only to fit the line into 80 chars?
> > If so, let's not do it. Lines up to 100 chars long are more readable than
> this I
> > believe.
> I changed it to conform to PEP8 and increase readability on editors adjusted
> to 80 chars. However, if you consider it's better to leave it on 100 chars,
> I could work within that.

Let's agree on max 100 chars/line if it improves readability. Otherwise
80 is ok.

> > > +        self.assertEqual(0, runCmd("wic create directdisk "
> > > +                                   "--image-name=%s "
> > > +                                   "--vars %s"
> > > +                                   % (image, imgenvdir)).status)
> > > +
> > Do we really want to test short and long variant of options?
> > If so, we should do it for all options.
> Within the module, all short and long variant of options are tested. Not all
> combinations of long variants with '=' and without it are tested, though.

OK, makes sense to me.

> > > +    @testcase(1562)
> > > +    def test_alternate_output_dir(self):
> > > +        """Test alternate output directory"""
> > > +        self.assertEqual(0, runCmd("wic create directdisk "
> > > +                                   "-e core-image-minimal "
> > > +                                   "-o %s"
> > > +                                   % self.alternate_resultdir).status)
> > > +        self.assertEqual(1, len(glob(self.alternate_resultdir +
> > > +                                     "build/directdisk-*.direct")))
> > > +        self.assertEqual(0, runCmd("wic create mkefidisk -e "
> > > +                                   "core-image-minimal "
> > > +                                   "--outdir %s"
> > > +                                   % self.alternate_resultdir).status)
> > > +        self.assertEqual(1, len(glob(self.alternate_resultdir +
> > > +                                     "build/mkefidisk-*direct")))
> > Would one test be enough?
> I'm using both output option variants to increase coverage.
yep, understood.

> > BTW, did you measure how long does the test run before and after your
> > changes? We should be careful here as this test runs on ab and makes
> people
> > wait longer for results.
> Agreed. I didn't do it, but I'll measure it and take it into account for my
> next update.

Great! It would be interesting to look at the numbers.


--
Regards,
Ed


      reply	other threads:[~2016-12-14 11:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-13 15:53 [PATCH] selftest/wic: extending test coverage for WIC script options Jair Gonzalez
2016-12-13 20:17 ` Ed Bartosh
2016-12-14  0:24   ` Jair Gonzalez
2016-12-14 11:44     ` Ed Bartosh [this message]

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=20161214114430.GA19511@linux.intel.com \
    --to=ed.bartosh@linux.intel.com \
    --cc=jair.de.jesus.gonzalez.plascencia@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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