[parted-devel] add integration tests

[Jim Meyering]

Otavio Salvador <otavio at debian.org> wrote:

> Jim Meyering <jim at meyering.net> writes:
>
>> Some renaming would be fine with me.
>> However, these suggestions
>>
>>   lang-default -> environment
>>   priv-check -> test-root
>>
>> seem backwards.
>>
>> The first one is concerned solely with language-related envvars, so
>> "environment" is too general.  In fact, in coreutils I have another
>> such script called envvar-check that ensures that over a dozen misc
>> envvars are unset, so that their values don't interfere with
>> testing.  The lang-default script is solely to ensure that the
>> language used in parted diagnostics is English.
>
> In this case we then might use the name 'set-english-language' since
> it's meaning of the script.

Sorry, but that's not it, either.  That might imply setting
the locale to e.g., en_US.utf8, which we don't want.
What we really want is the "default" ("C") locale.
I.e., not english per-se, but the most basic, non-translated
(not even to some english dialect) messages.

>> The second tests whether the script is being run with elevated
>> privileges.  I deliberately chose not to use "root" in its name,
>> since the user name of the privileged user need not be "root",
>> though in practice it usually is.
>
> Then use: 'as-superuser'?

This script isn't even used yet, though it was in an
early iteration, and will be.
If you saw examples of use, it'd be clearer why it's
named the way it is:

Some tests must be run by "root":
  PRIV_CHECK_ARG=require-root . $srcdir/../priv-check

Some tests must *not* be run by "root":
  PRIV_CHECK_ARG=require-non-root . $srcdir/../priv-check

Actually, the whole idea of having one function per script
and "sourcing" each file is rather anachronistic.  The only
reason it's that way in coreutils is that there are still
a few very old systems out there with no function-supporting
bourne/korn shell.  For parted, we can use a cleaner
approach: maintain a library of test-related shell functions,
probably all in one file, and use those from each test script.
Then, the bit in question becomes a function name, which is
far easier to change than a file name.