[Libguestfs] [PATCH 3/6] v2v:test:win: actually check the eventual layout

[Roman Kagan]

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.