doc tweaks (Autotest chapter)

[Ralf Wildenhues]

I have a list of minor doc tweaks.  Not being native speaker, please
take them with a grain of salt.

Regards,
Ralf

2004-11-29  Ralf Wildenhues <address@hidden>

        * doc/autoconf.texi (Generating Test Suites with Autotest):
        Minor doc tweaks.

Index: doc/autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.845
diff -u -r1.845 autoconf.texi
--- doc/autoconf.texi   29 Nov 2004 04:29:08 -0000      1.845
+++ doc/autoconf.texi   29 Nov 2004 07:57:52 -0000
@@ -15138,7 +15138,7 @@
 To circumvent this problem many package maintainers have developed their
 own testing framework, based on simple shell scripts whose sole output
 are their exit status: the test succeeded, or failed.  In addition, most
-of these tests share some common patterns, what results in lots of
+of these tests share some common patterns, which results in lots of
 duplicated code, tedious maintenance etc.
 
 Following exactly the same reasoning that yielded to the inception of
@@ -15151,7 +15151,7 @@
 it has considerably improved the strength of the test suite, and the
 quality of bug reports.  Other projects are known to use some generation
 of Autotest, such as Bison, Free Recode, Free Wdiff, @acronym{GNU} Tar, each of
-them having different needs, what slowly polishes Autotest as a general
+them having different needs, which slowly polishes Autotest as a general
 testing framework.
 
 Nonetheless, compared to address@hidden, Autotest is inadequate for
@@ -15190,15 +15190,15 @@
 executed together, usually because one test in the group creates data
 files than a later test in the same group needs to read.  Complex test
 groups make later debugging more tedious.  It is much better keeping
-keep only a few tests per test group, and if you can put only one test
+only a few tests per test group, and if you can put only one test
 per test group, this is just ideal.
 
 For all but the simplest packages, some file such as @file{testsuite.at}
 does not fully hold all test sources, as these are often easier to
 maintain in separate files.  Each of these separate files holds a single
 test group, or a sequence of test groups all addressing some common
-functionality in the package.  In such cases, file @file{testsuite.at}
-only initializes the whole validation suite, and sometimes do elementary
+functionality in the package.  In such cases, the file @file{testsuite.at}
+only initializes the whole validation suite, and sometimes does elementary
 health checking, before listing include statements for all other test
 files.  The special file @file{package.m4}, containing the
 identification of the package, is automatically included if found.
@@ -15231,7 +15231,7 @@
 @end itemize
 
 In the ideal situation, none of the tests fail, and consequently, no
-debugging directory is left out of validation.
+debugging directory is left for validation.
 
 It often happens in practice that individual tests in the validation
 suite need to get information coming out of the configuration process.
@@ -15365,8 +15365,8 @@
 
 Autotest test suites rely on the @env{PATH} to find the tested program.
 This saves from generating the absolute names of the various tools, and
-makes it possible to test installed programs.  Therefore, knowing what
-programs are being exercised is crucial to understand some problems in
+makes it possible to test installed programs.  Therefore, knowing which
+programs are being exercised is crucial to understanding some problems in
 the test suite itself, or its occasional misuses.  It is a good idea to
 also subscribe foreign programs you depend upon, to ease incompatibility
 diagnostics.