[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: `make check` mechanics

From: Karl Fogel <kfogel_at_collab.net>
Date: 2001-06-18 22:02:15 CEST

Ben Collins-Sussman <sussman@collab.net> writes:
> Sorry to beat a dead fish, but I'm bringing back this old topic. For
> the impatient, here's a quick recap:

I think your proposals sound good; would like to see if Kevin, Greg,
or anyone else has anything to say about it (knowing that Greg Stein
came back from his exotic weekend getaway today, he may not have seen
this mail yet).


> -------------------
> Ben: I dislike the the fact that when I run `make check`, every single
> test program is being passed $srcdir. Very few actually need it.
> Every C and python test program is warning us about ignoring garbage
> arguments. It's ugly.
> Kevin & Greg reply: No, tests might need external data in $srcdir.
> If srcdir != builddir, they need to be able to find the data.
> --------------------
> Ben replies:
> Only 3 scripts need external data files to run right now:
> * clients/cmdline/tests/svn-test*.sh
> These are the old M1 tests which exercise the client's ability to
> use and create XML files, written in bourne shell.
> These tests are planned to be rewritten in python. (Unlike our
> python tests, these XML tests aren't self-validating. They only
> look for returned errorcodes, instead of parsing commandline
> output and examining disk contents.)
> When rewritten in python, they'll be "self-contained",
> i.e. they'll write the XML input files to disk all by
> themselves -- just like our python tests automatically create a
> repository and import an "internalized" greek tree.
> * tests/libsvn_wc/checkout-test.c
> This is really old. It predates our C test framework, and it's
> redundant with the M1 tests above. (It just checks out a working
> copy from an XML file.) Honestly, it should be tossed. I'm
> going to nuke it.
> You can see where I'm going with this. Our current python and C tests
> are already "self contained", and when the XML tests are rewritten,
> they will be too. So I'm advocating that we make it a testing
> requirement. There should be no reason for a test to require external
> datafiles; the data is easy to bury in the test itself -- we're
> already doing it in both frameworks.
> The only side issue, then, is the case of disk writing. Our current
> python and C tests assume that it's safe to write out repositories
> and/or working copies in the CWD. So if srcdir != builddir, and
> srcdir is not writable, we're still ok: when we get vpath builds
> working again, `make check` just needs to make sure that it *doesn't*
> cd into the test's directory (as it currently does), and that the CWD
> is writable.
> Here's the order I'd like to see things happen:
> 1. tweak the 2 xml-test scripts to *not* require $srcdir. Let them
> assume hardcoded relative paths to the external files for now.
> `make check` is cd'ing into their directory anyway.
> 2. stop `make check` from passing $srcdir to every darn test. It's
> so ugly.
> 3. port the xml tests to our python framework.
> 4. get vpath builds working.
> I would like to carry out items 1 and 2 above this week. Items 3 and
> 4 can be done later at our leisure, since they're larger projects and
> not high priority right now.
> In a nutshell: we have an ugliness in our test system, for the sake of
> a feature that doesn't yet exist and for scripts that soon *won't*
> exist. Let clean it up now, and get it perfect later on.
> Donning asbestos,
> -Ben
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:32 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.