testing.html grammar/spelling errors
|User & Date:||anonymous 2010-05-07 16:07:41|
- Appended to comment:
anonymous claiming to be eas added on 2010-05-07 16:07:41:
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.
--- 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
- Change priority to "Low"
- Change resolution to "Open"
- Change severity to "Minor"
- Change status to "Open"
- Change title to "testing.html grammar/spelling errors"