Re: [Libguestfs] [PATCH 3/6] v2v:test:win: actually check the eventual layout
On Mon, Oct 05, 2015 at 03:42:46PM +0200, Pino Toscano wrote:
On Monday 05 October 2015 16:34:31 Roman Kagan wrote:
> On Mon, Oct 05, 2015 at 03:19:21PM +0200, Pino Toscano wrote:
> > On Monday 05 October 2015 16:05:54 Roman Kagan wrote:
> > > On Mon, Oct 05, 2015 at 02:50:52PM +0200, Pino Toscano wrote:
> > > > On Monday 05 October 2015 15:40:03 Roman Kagan wrote:
> > > > > +{
> > > > > guestfish --ro -a $d/windows-sda -i <<EOF
> > > > > + trace 1
> > > > > is-dir "/Program Files/Red Hat/Firstboot"
> > > > > is-file "/Program Files/Red
Hat/Firstboot/firstboot.bat"
> > > > > is-dir "/Program Files/Red Hat/Firstboot/scripts"
> > > > > is-dir "/Windows/Drivers/VirtIO"
> > > > > + trace 0
> > > > > EOF
> > > > > +} | {
> > > > > + ret=0
> > > > > + while read r; do
> > > > > + [ "$r" = "true" ] || ret=1
> > > > > + done
> > > > > + exit $ret
> > > > > +}
> > > >
> > > > Note we have tests that check the output of guestfish -- for
example,
> > > > fish/test-edit.sh (it is not the only one). I guess you could turn
this
> > > > test to do the same, which could be also easier to expand if there
will
> > > > be added more commands that output things different than
"true".
> > >
> > > Yes I have seen it but exactly because I foresee nothing but
"true" in
> > > guestfish's output I want to avoid tedious beancounting when
maintaining
> > > the expected result string.
> >
> > Never say never... really, better make it slightly more generic, so
> > expanding it later is no hassle.
>
> It sure is. E.g. in another patch in the series I add more is-file
> commands here, and I generate them with a shell "for" loop; a constant
> string for the expected reply with a dozen of "true" lines would look
> weird IMO.
Again: what if tomorrow we add checks that output something different
than "true"?
We'll address that tomorrow when we see the demand. ATM there's a
demand to add more "true" lines, and do so programmatically; a constant
expected reply string is a poor fit for this job.
Also, printing all the output on error would help in
debugging eventual failures of this guestfish run.
It wouldn't as you have no means to match the path to the result of the
check.
> > Also, comparing to the exact output expected is a check more that we
> > got the number of lines expected.
>
> This is rather a check for guestfish which we assume already tested
> here.
More checks don't hurt, I'd say.
They sure do if they add maintenance cost at little testing value.
Roman.