[parted-devel] add integration tests
Jim Meyering
jim at meyering.net
Thu Apr 26 21:50:15 UTC 2007
Otavio Salvador <otavio at debian.org> wrote:
> The integration tests looks ok but the directory structure will get
> messy due the number of tests we can have. I'd rather suggest to use
> something like:
>
> tests/
> lib/
> environment (replacing lang-default)
> test-root (replacing priv-check)
> mklabel/
> script-mode (replacing label-01)
> works (replacing label-02)
> mkpart/
> fail-too-smal (replacing part-01)
> works (replacing part-02)
>
> I think that all files inside of lib might be sourced as had been done
> on the current test framework but making them inside of lib would
> allow a better organization and everyone knows a bit better what each
> one are suppose to do.
Thanks for the feedback.
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.
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.
As for the other renamings, I have a strong aversion to adding
hierarchy. I did that for coreutils, and with nearly 100 programs,
if I'd created one directory for each it'd be a real mess.
As it is, coreutils/tests/ has 45 subdirs, and that is far too many.
Leads to unnecessary duplication in Makefile.am, and other maintenance
hassles, not to mention a small build-time performance hit.
I like the way it's done in git/t, with number prefixes to help group
test file names (though we wouldn't need that, since the list of names
is in Makefile.am) and with everything in one directory.
Also, these days we needn't worry about long names, so I will
definitely use more descriptive (and longer) names.
I'll spend some time on this tomorrow.
More information about the parted-devel
mailing list