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

Re: make check

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-06-01 18:59:34 CEST

Ben Collins-Sussman <sussman@collab.net> writes:

> Or maybe a more elegant strategy is not to have our 'make check' rule
> pass $abs_srcdir to every darn test. Only 2 scripts require it, and
> *all* the other test programs have to be coded to ignore what they all
> consider a bogus arg. That seems clunky to me. Maybe we can an
> optional build.conf attribute that allows one to specify a particular
> sets of args to a test? I mean, it seems like we're coding for the
> exception now, not the rule.

Let me follow up to myself. After talking with Karl, here are my
latest thoughts for how things should probably work:

1. All test programs (be they binaries or scripts) live somewhere in

2. Each test program should verify its own location in the
    tree. (This can be done by looking for "../../../README" or

3. Once each program verifies its location, it can make any
    assumptions it wants about where things are. The xml scripts can
    assume where the .xml files live, the fs tests can assume its safe
    to write repositories to their CWD, and so on.

If these three rules are followed, then there's really no reason for
any test to *ever* require an argument. If a test program happens to
accept arguments, they will be for optional conveniences only (like
"please run test 7").

Remember, we're trying to write automated tests, not super-flexible
scripts. That means 80% of the time they're going to be run by 'make
check' from the top level, and 20% of the time a single test will be
hand-executed by a developer. But we don't need to worry about
executing these tests all over the system. Let them live happily as
stationary objects in our source tree.

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:31 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.