testing.html uses 'insure' inappropriately. The correct word is 'ensure'.
<hr><i>drh added on 2009-03-18 14:45:41:</i><br>
I reviewed the subtle distinction between "ensure" and "insure" at
[http://www.merriam-webster.com/dictionary/ensure] and the text of
the testing.html document, and I think the use of "insure" in testing.html
is correct. If you disagree, please explain why.
<hr><i>anonymous claiming to be eas added on 2010-05-07 16:07:41:</i><br>
drh,
The original complaint was definitely correct. "Insure" means "enter into an insurance contract as the provider". "Ensure" means "make sure". Clearly the intent in the doc is the latter.
I was reading through testing.html last night for the umpteenth time and decided it might be helpful to generate a patch for all the typos that leapt out. That is appended below.
Only the "insure/ensure" thing and other obvious syntactic/spelling/consistency errors are corrected--I've made no attempt at any style prescription.
<verbatim>
--- testing.html 2010-03-31 07:58:55.000000000 -0400
+++ testing.eas.html 2010-05-07 11:01:28.386566309 -0400
@@ -248,7 +248,7 @@
of SQLite when something goes wrong. It is (relatively) easy to build
an SQL database engine that behaves correctly on well-formed inputs
on a fully functional computer. It is more difficult to build a system
-that responses sanely to invalid inputs and continues to function following
+that responds sanely to invalid inputs and continues to function following
system malfunctions. The anomaly tests are designed to verify the latter
behavior.</p>
@@ -257,7 +257,7 @@
<h3>3.1 Out-Of-Memory Testing</h3>
<p>SQLite, like all SQL database engines, makes extensive use of
-malloc() (See the separate report on
+malloc(). (See the separate report on
<a href="malloc.html">dynamic memory allocation in SQLite</a> for
additional detail.)
On servers and workstations, malloc() never fails in practice and so correct
@@ -368,7 +368,7 @@
<h3>3.4 Compound failure tests</h3>
<p>The test suites for SQLite also explore the result of stacking
-multiple failures. For example, tests are run to insure correct behavior
+multiple failures. For example, tests are run to ensure correct behavior
when an I/O error or OOM fault occurs while trying to recover from a
prior crash.
@@ -377,7 +377,7 @@
<h2>4.0 Fuzz Testing</h2>
<p><a href="http://en.wikipedia.org/wiki/Fuzz_testing">Fuzz testing</a>
-seeks to establish that SQLite response correctly to invalid, out-of-range,
+seeks to establish that SQLite responds correctly to invalid, out-of-range,
or malformed inputs.</p>
<h3>4.1 SQL Fuzz</h3>
@@ -434,7 +434,7 @@
fixed until new test cases have been added to the TCL test suite which
would exhibit the bug in an unpatched version of SQLite. Over the years,
this has resulted in thousands and thousands of new tests being added
-to the TCL test suite. These regression tests insure that bugs that have
+to the TCL test suite. These regression tests ensure that bugs that have
been fixed in the past are not reintroduced into future versions of
SQLite.</p>
@@ -446,10 +446,10 @@
are allocated and never freed. The most troublesome resource leaks
in many applications are memory leaks - when memory is allocated using
malloc() but never released using free(). But other kinds of resources
-can also be linked: file descriptors, threads, mutexes, etc.</p>
+can also be leaked: file descriptors, threads, mutexes, etc.</p>
<p>Both the TCL and TH3 test harnesses automatically track system
-resources and report resources leaks on <u>every</u> test run.
+resources and report resource leaks on <u>every</u> test run.
No special configuration or setup is required. The test harnesses
are especially vigilant with regard to memory leaks. If a change
causes a memory leak, the test harnesses will recognize this
@@ -482,7 +482,7 @@
of lines of code are executed at least once by the test suite.</p>
<p>Branch coverage is more rigorous than statement coverage. Branch
-coverage measure the number of machine-code branch instructions that
+coverage measures the number of machine-code branch instructions that
are evaluated at least once on both directions.</p>
<p>To illustrate the difference between statement coverage and
@@ -575,7 +575,7 @@
<p>Another macro used in conjunction with test coverage measurement is
the <tt>testcase()</tt> macro. The argument is a condition for which
we want test cases that evaluate to both true and false.
-In non-coverage builds (that is to so, in release builds) the testcase()
+In non-coverage builds (that is to say, in release builds) the testcase()
macro is a no-op:</p>
<blockquote><pre>
@@ -585,7 +585,7 @@
<p>But in a coverage measuring build, the testcase() macro generates code
that evaluates the conditional expression in its argument.
Then during analysis, a check
-is made to insure tests exists that evaluate the conditional to both true
+is made to ensure tests exist that evaluate the conditional to both true
and false. Testcase() macros are used, for example, to help verify that
boundary values are tested. For example:</p>
@@ -612,11 +612,12 @@
}
</pre></blockquote>
-<p>For bitmask tests, testcase() macros are used to verify that every
-bit of the bitmask effects the test. For example, in the following block
+<p>For bitmask tests, <tt>testcase()</tt> macros are used to verify that every
+bit of the bitmask affects the test. For example, in the following block
of code, the condition is true if the mask contains either of two bits
-indicating either a MAIN_DB or a TEMP_DB is being opened. The testcase()
-macros that precede the if statement verify that both cases are tested:</p>
+indicating either a MAIN_DB or a TEMP_DB is being opened. The
+<tt>testcase()</tt> macros that precede the <tt>if</tt> statement verify that
+both cases are tested:</p>
<blockquote><pre>
testcase( mask & SQLITE_OPEN_MAIN_DB );
@@ -625,7 +626,7 @@
</pre></blockquote>
<p>The SQLite source code contains 558
-uses of the testcase() macro.</p>
+uses of the <tt>testcase()</tt> macro.</p>
<a name="mcdc"></a>
@@ -710,7 +711,7 @@
an x86 running a linux binary. (Ports of valgrind for platforms other
than linux are in development, but as of this writing, valgrind only
works reliably on linux, which in the opinion of the SQLite developers
-means that linux should be preferred platform for all software development.)
+means that linux should be the preferred platform for all software development.)
As valgrind runs a linux binary, it looks for all kinds of interesting
errors such as array overruns, reading from uninitialized memory,
stack overflows, memory leaks, and so forth. Valgrind finds problems
@@ -758,7 +759,7 @@
<h3>8.5 Journal Tests</h3>
-<p>One of the things that SQLite does to insure that transactions
+<p>One of the things that SQLite does to ensure that transactions
are atomic across system crashes and power failures is to write
all changes into the rollback journal file prior to changing the
database. The TCL test harness contains an alternative
@@ -805,7 +806,7 @@
<h2>10.0 Summary</h2>
-<p>SQLite is open source. This gives many people with the idea that
+<p>SQLite is open source. This gives many people the idea that
it is not well tested as commercial software and is perhaps unreliable.
But that impression is false.
SQLite has exhibited very high reliability in the field and
</verbatim>
<hr><i>anonymous claiming to be eas added on 2010-05-07 18:40:12:</i><br>
Checking your source tree, I found a 'testing.in' which I assume gets filtered through some script or another on its way to becoming a real web page. I made a similar patch to that file, assuming patch(1) will work better on with it:
<verbatim>
--- testing.in 2010-05-07 14:32:05.944821183 -0400
+++ testing.eas.in 2010-05-07 14:36:22.026567435 -0400
@@ -212,7 +212,7 @@
of SQLite when something goes wrong. It is (relatively) easy to build
an SQL database engine that behaves correctly on well-formed inputs
on a fully functional computer. It is more difficult to build a system
-that responses sanely to invalid inputs and continues to function following
+that responds sanely to invalid inputs and continues to function following
system malfunctions. The anomaly tests are designed to verify the latter
behavior.</p>
@@ -220,7 +220,7 @@
<h3>3.1 Out-Of-Memory Testing</h3>
<p>SQLite, like all SQL database engines, makes extensive use of
-malloc() (See the separate report on
+malloc(). (See the separate report on
[memory allocation | dynamic memory allocation in SQLite] for
additional detail.)
On servers and workstations, malloc() never fails in practice and so correct
@@ -328,7 +328,7 @@
<h3>3.4 Compound failure tests</h3>
<p>The test suites for SQLite also explore the result of stacking
-multiple failures. For example, tests are run to insure correct behavior
+multiple failures. For example, tests are run to ensure correct behavior
when an I/O error or OOM fault occurs while trying to recover from a
prior crash.
@@ -336,7 +336,7 @@
<h2>4.0 Fuzz Testing</h2>
<p>[http://en.wikipedia.org/wiki/Fuzz_testing | Fuzz testing]
-seeks to establish that SQLite response correctly to invalid, out-of-range,
+seeks to establish that SQLite responds correctly to invalid, out-of-range,
or malformed inputs.</p>
<h3>4.1 SQL Fuzz</h3>
@@ -392,7 +392,7 @@
fixed until new test cases have been added to the TCL test suite which
would exhibit the bug in an unpatched version of SQLite. Over the years,
this has resulted in thousands and thousands of new tests being added
-to the TCL test suite. These regression tests insure that bugs that have
+to the TCL test suite. These regression tests ensure that bugs that have
been fixed in the past are not reintroduced into future versions of
SQLite.</p>
@@ -403,10 +403,10 @@
are allocated and never freed. The most troublesome resource leaks
in many applications are memory leaks - when memory is allocated using
malloc() but never released using free(). But other kinds of resources
-can also be linked: file descriptors, threads, mutexes, etc.</p>
+can also be leaked: file descriptors, threads, mutexes, etc.</p>
<p>Both the TCL and TH3 test harnesses automatically track system
-resources and report resources leaks on <u>every</u> test run.
+resources and report resource leaks on <u>every</u> test run.
No special configuration or setup is required. The test harnesses
are especially vigilant with regard to memory leaks. If a change
causes a memory leak, the test harnesses will recognize this
@@ -437,7 +437,7 @@
of lines of code are executed at least once by the test suite.</p>
<p>Branch coverage is more rigorous than statement coverage. Branch
-coverage measure the number of machine-code branch instructions that
+coverage measures the number of machine-code branch instructions that
are evaluated at least once on both directions.</p>
<p>To illustrate the difference between statement coverage and
@@ -528,17 +528,17 @@
<p>Another macro used in conjunction with test coverage measurement is
the <tt>testcase()</tt> macro. The argument is a condition for which
we want test cases that evaluate to both true and false.
-In non-coverage builds (that is to so, in release builds) the testcase()
-macro is a no-op:</p>
+In non-coverage builds (that is to say, in release builds) the
+<tt>testcase()</tt> macro is a no-op:</p>
<blockquote><pre>
#define testcase(X)
</pre></blockquote>
-<p>But in a coverage measuring build, the testcase() macro generates code
-that evaluates the conditional expression in its argument.
+<p>But in a coverage measuring build, the <tt>testcase()</tt> macro generates
+code that evaluates the conditional expression in its argument.
Then during analysis, a check
-is made to insure tests exists that evaluate the conditional to both true
+is made to ensure tests exist that evaluate the conditional to both true
and false. Testcase() macros are used, for example, to help verify that
boundary values are tested. For example:</p>
@@ -565,11 +565,12 @@
}
</pre></blockquote>
-<p>For bitmask tests, testcase() macros are used to verify that every
+<p>For bitmask tests, <tt>testcase()</tt> macros are used to verify that every
bit of the bitmask effects the test. For example, in the following block
of code, the condition is true if the mask contains either of two bits
-indicating either a MAIN_DB or a TEMP_DB is being opened. The testcase()
-macros that precede the if statement verify that both cases are tested:</p>
+indicating either a MAIN_DB or a TEMP_DB is being opened. The
+<tt>testcase()</tt> macros that precede the if statement verify that both
+cases are tested:</p>
<blockquote><pre>
testcase( mask & SQLITE_OPEN_MAIN_DB );
@@ -578,7 +579,7 @@
</pre></blockquote>
<p>The SQLite source code contains <tcl>N {$stat(nTestcase)}</tcl>
-uses of the testcase() macro.</p>
+uses of the <tt>testcase()</tt> macro.</p>
<tcl>hd_fragment {mcdc} *MC/DC {MC/DC testing}</tcl>
<h3>7.4 Branch coverage versus MC/DC</h3>
@@ -658,7 +659,7 @@
an x86 running a linux binary. (Ports of valgrind for platforms other
than linux are in development, but as of this writing, valgrind only
works reliably on linux, which in the opinion of the SQLite developers
-means that linux should be preferred platform for all software development.)
+means that linux should be the preferred platform for all software development.)
As valgrind runs a linux binary, it looks for all kinds of interesting
errors such as array overruns, reading from uninitialized memory,
stack overflows, memory leaks, and so forth. Valgrind finds problems
@@ -703,7 +704,7 @@
<tcl>hd_fragment journaltest</tcl>
<h3>8.5 Journal Tests</h3>
-<p>One of the things that SQLite does to insure that transactions
+<p>One of the things that SQLite does to ensure that transactions
are atomic across system crashes and power failures is to write
all changes into the rollback journal file prior to changing the
database. The TCL test harness contains an alternative
@@ -748,7 +749,7 @@
<tcl>hd_fragment summary</tcl>
<h2>10.0 Summary</h2>
-<p>SQLite is open source. This gives many people with the idea that
+<p>SQLite is open source. This gives many people the idea that
it is not well tested as commercial software and is perhaps unreliable.
But that impression is false.
SQLite has exhibited very high reliability in the field and
</verbatim>
|