Re: Writing tests for gvfs

[Alexander Larsson <alexl redhat com>]

On tor, 2012-09-20 at 18:31 +0200, Martin Pitt wrote:

> > >  - http://people.canonical.com/~pitti/tmp/gvfs-testbed
> > > 
> > >    Wrapper which builds a "sandbox" in the sense of using a temporary
> > >    /tmp, /etc/, and /home, and creating a temporary "testuser" user in
> > >    the sandbox. It uses unshare(1) with tmpfs bind mounts, so it's
> > >    both very quick and safe - all the bind mounts will be cleaned up
> > >    automatically as soon as the program terminates, and cannot be
> > >    accessed from outside, so they do not interfere with the system
> > >    (well, some stuff like useradd does log to /var/log/auth.log, but
> > >    that can be covered by bind mounts as well eventually)
> > 
> > Another approach would be to use a real VM as testbed.
> 
> In production [1] we do run them in VMs, of course. For that the tmpfs
> magic is not necessary of course, and the wrapper script could be
> reduced to just set up a test user, etc.
> 
> I just like having that sandbox because it's magnitudes faster and
> slightly more convenient (it takes no noticeable time at all) than the
> juggling with a VM during test development.
> 
> However, in both cases the actual tests (the first script, gvfs-test)
> is the same. So if you don't particularly like gvfs-testbed, I'm happy
> to keep that on the Debian/Ubuntu side for now.

I agree, it would be nice to have some "quick" tests that the developer
can run on his own machine without much setup, as long as we can also
have some buildbot run a more extensive vm-based test using the same
tests. Just wanted to mention the VM side as that is the only way of
testing some things, like win32 integration and specific server
versions.

> [1] https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-gvfs/
> 
> > We could even ship a pre-built one with whatever dependencies is
> > needed.
> 
> Shipping a complete VM? That sounds a bit big..

Yeah, its obviously not something we could ship in the tarball. But
having it available for gvfs developers to download is not *that*
extreme, is it? Only the people interested in it would need to download
it, and ideally it should not change that often anyway.

> > > So, my questions:
> > > 
> > >  - First, are you interested in eventually adding integration tests to
> > >    the upstream git at all? If not, I can put it into the
> > >    Debian/Ubuntu packaging where they will be run as part of
> > >    https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/ but
> > >    that would make them a lot less useful for other developers.
> > 
> > Yes, we're very interested in this. Its sadly lacking in the 
>
> ... Phone rang? Pizza was ready? :-)

lacking in time and resources to do the actual work.

> > it *should* be able to run from the build tree
> 
> the LD_LIBRARY_PATH and friends are not a problem, but gvfs needs to
> find and access all its .service files and the like; I tried a "make
> install" into ./test-inst/ and some seddery in the .service files, but
> I didn't get it to run. But I shall try harder.

Yeah, it should be possible to sed the .service.in and .mount.in files
to create in-tree usable versions in some in-tree prefix, then just
point the dbus instance you read to that directory using XDG_DATA_DIRS.

And, as i said, you need to modify daemon/mount.c so you can point
MOUNTABLE_DIR do this directory at runtime too.

> Do you want the current system integration tests upstream already
> ("make installcheck" seems to be a rather common name), or wait a bit
> until they matured a bit? Start of 3.7 cycle might be a good time?

Start of 3.7 cycle seems like a good time to me.

> > and various different types of ftp servers too, as these behave
> > rather differently at times.
> 
> Ah, do you have a concrete example (bug report or so) which I should
> add? Right now I only run the python twisted FTP server, as that's
> easiest to use.

Well, for instance, the LIST command in ftp basically returns the output
of the local "ls"-like command. On a unix server this is is "ls", but on
win32 its "dir" and on vms its something completely different. Also,
there are various levels of extensions to the ftp protocol that we look
for and use only if the server supports it.